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
