any update here? This is relevant for a currently open PR of mine -- I've got a bunch of new public constants defined w/ format #4, but I'd gladly switch to java enums. (Even if we are just going to postpone this decision, I'm still inclined to switch to java enums ...)
just to be clear about the existing problem with enums & scaladoc: right now, the scaladoc knows about the enum class, and generates a page for it, but it does not display the enum constants. It is at least labeled as a java enum, though, so a savvy user could switch to the javadocs to see the constants. On Mon, Mar 23, 2015 at 4:50 PM, Imran Rashid <iras...@cloudera.com> wrote: > 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 >> > >> > >
