well, perhaps I overstated things a little, I wouldn't call it the "official" solution, just a recommendation in the never-ending debate (and the recommendation from folks with their hands on scala itself).
Even if we do get this fixed in scaladoc eventually -- as its not in the current versions, where does that leave this proposal? personally I'd *still* prefer java enums, even if it doesn't get into scaladoc. btw, even with sealed traits, the scaladoc still isn't great -- you don't see the values from the class, you only see them listed from the companion object. (though, that is somewhat standard for scaladoc, so maybe I'm reaching a little) On Mon, Mar 23, 2015 at 4:11 PM, Patrick Wendell <pwend...@gmail.com> wrote: > If the official solution from the Scala community is to use Java > enums, then it seems strange they aren't generated in scaldoc? Maybe > we can just fix that w/ Typesafe's help and then we can use them. > > On Mon, Mar 23, 2015 at 1:46 PM, Sean Owen <so...@cloudera.com> wrote: > > Yeah the fully realized #4, which gets back the ability to use it in > > switch statements (? in Scala but not Java?) does end up being kind of > > huge. > > > > I confess I'm swayed a bit back to Java enums, seeing what it > > involves. The hashCode() issue can be 'solved' with the hash of the > > String representation. > > > > On Mon, Mar 23, 2015 at 8:33 PM, Imran Rashid <iras...@cloudera.com> > wrote: > >> I've just switched some of my code over to the new format, and I just > want > >> to make sure everyone realizes what we are getting into. I went from 10 > >> lines as java enums > >> > >> > https://github.com/squito/spark/blob/fef66058612ebf225e58dd5f5fea6bae1afd5b31/core/src/main/java/org/apache/spark/status/api/StageStatus.java#L20 > >> > >> to 30 lines with the new format: > >> > >> > https://github.com/squito/spark/blob/SPARK-3454_w_jersey/core/src/main/scala/org/apache/spark/status/api/v1/api.scala#L250 > >> > >> its not just that its verbose. each name has to be repeated 4 times, > with > >> potential typos in some locations that won't be caught by the compiler. > >> Also, you have to manually maintain the "values" as you update the set > of > >> enums, the compiler won't do it for you. > >> > >> The only downside I've heard for java enums is enum.hashcode(). OTOH, > the > >> downsides for this version are: maintainability / verbosity, no > values(), > >> more cumbersome to use from java, no enum map / enumset. > >> > >> I did put together a little util to at least get back the equivalent of > >> enum.valueOf() with this format > >> > >> > https://github.com/squito/spark/blob/SPARK-3454_w_jersey/core/src/main/scala/org/apache/spark/util/SparkEnum.scala > >> > >> I'm not trying to prevent us from moving forward on this, its fine if > this > >> is still what everyone wants, but I feel pretty strongly java enums make > >> more sense. > >> > >> thanks, > >> Imran > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@spark.apache.org > > For additional commands, e-mail: dev-h...@spark.apache.org > > >
