Hi everyone,
while I'm far from finished, I'd like to propose a SIP, whose goal is to provide better support for enums in Scala and improve compatibility with the runtime.
The goal is the inclusion in the upcoming version of Scala (and the deprecation of scala.Enumeration).
Short syntax primer:
@Enum
class Day {
Monday
Tuesday
Wednesday
Thursday
Friday
}
Usage (from Java(!)):
Day mon = Day.Monday();
int ord = mon.ordinal();
assert Day.class.getClass().isEnum();
The document is here: https://docs.google.com/document/d/1mIKml4sJzezL_-iDJMmcAKmavHb9axjYJos_7UMlWJ8/edit#
I would be happy about feedback, criticisms and suggestions!
Please let me know what you think!
--
You received this message because you are subscribed to the Google Groups "scala-sips" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-sips+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
I would like to see how this will marshal to json. Current Scala Enumeration requires to save in the json the class name. Because of that i am still using Java enums in my Scala project.Can you explain how it will be mapped to json inside complex objects?
--
You received this message because you are subscribed to a topic in the Google Groups "scala-sips" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/scala-sips/Bf82LxK02Kk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to scala-sips+...@googlegroups.com.
1- @enum uncapitalized is more scala-ish than @Enum
2- Is it possible to emit enum fields as static field members instead of static methods? With the current approach, it will be not possible to use scala enums on Java annotation fields, i.e. @MyAnnotation(value = Day.Monday()) is forbidden in Java.
3- Retrieving a mutable array of values() is Java compatible, but from scala perspective, inmutable is preferred. May be there is not a good solution for this issue.
4- ¿Will pattern matching be supported?
Hi Simon, your work looks very cool! Believe it or not, lack of proper java compatible enums, was stopping me from choice scala for many works.
--
You received this message because you are subscribed to the Google Groups "scala-sips" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-sips+...@googlegroups.com.
I personally find the sealed-trait + case object enum a better solution for Scala since it provides exhaustiveness checking -- though I understand it sacrifices Java interop.
Do you see any possible issues with user defined constructors and overrides? (as described in the SIP)
1) I understand that the macro will generate enum fields like this: new Day("Monday", 1);What is to prevent users doing the same thing and creating new instances? Should the class be sealed?
2) values() defensively clones the value array on each invocation. Bad luck for Java interop but for the Scala-side, what do you think about adding another method that returns the values, say, as an immutable list? That should yield a little performance saving, arguably not worth the effort or the divergence with java enums but there you go.
And then there's the syntax; it horrifies me.
For Java interop, which I gather is the major motivating factor -- surely people concerned with interop can't be that concerned with defining enums in Java.
TL;DR it doesn't smell like Scala - not very orthogonal, special snowflake syntax.
+1 on all of Ken's points, but especially these two:For Java interop, which I gather is the major motivating factor -- surely people concerned with interop can't be that concerned with defining enums in Java.Hallelujah. Interop code is allowed to be a little messy so long as it's simple and easy to reason about.
TL;DR it doesn't smell like Scala - not very orthogonal, special snowflake syntax.Couldn't agree more. I actually don't find Scala's Enumeration construct all that bad -- it's messy behind the scenes, but that's precisely the point, I don't really care about what goes on behind the scenes.
My vote, FWIW, is to create enums and annotations that are better than java, like the rest of scala, and maybe allow an easier way of writing java enums and annotarions if there's a need. For example, a java{...} similar to c's assembly dowgrade. I don't think anyone will mind...
--
--
You received this message because you are subscribed to the Google Groups "scala-sips" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-sips+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
My vote, FWIW, is to create enums and annotations that are better than java, like the rest of scala,
and maybe allow an easier way of writing java enums and annotarions if there's a need. For example, a java{...} similar to c's assembly dowgrade. I don't think anyone will mind...
To clarify my arguments against the original proposition, there are really two major criticisms:
- Specialized syntax: the enum declaration above looks nothing like any other Scala class declaration. If you're going to go with new syntax, at least call it what it is and add an "enum" keyword to Scala. I'm against this, by the way, because I believe this goes against the Scala orthogonality/language simplicity guiding principle, whereas the current Scala enum construct is actually a library feature that builds on top of the language instead of adding to it.
- This doesn't solve a fundamental interop problem because, as mentioned earlier, the generated underlying class does not actually provide stable identifiers, which means it cannot be used in annotations. This makes it a no-win solution in my opinion.
At the cost of slightly more syntax, could this be an acceptable compromise?
@enum object DayOfWeek {
val Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, Sunday: DayOfWeek
}
Disadvantages: the extra text 'val' and ': DayOfWeek'
Advantages:
* No longer implies that something is being executed, merely declared
* Slightly less magic (to my eyes) about what will be treated as an enum value and what is object initialization code (the heuristic would be: any declared but undefined members in an @enum object which are typed with the object's companion class (regardless of whether the companion is declared in code) are enum values)
* The surface syntax coincides with the signature of the generated object--from Scala's perspective, these values will end up as vals on the object with the appropriate type
--
Any thoughts?
Thanks,
Simon
same as above:
- How would enums with constructors work?
- How would overridden methods work?