spark-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Xiangrui Meng <men...@gmail.com>
Subject Re: enum-like types in Spark
Date Fri, 10 Apr 2015 00:16:00 GMT
Using Java enums sound good. We can list the values in the JavaDoc and
hope Scala will be able to correctly generate docs for Java enums in
the future. -Xiangrui

On Thu, Apr 9, 2015 at 10:59 AM, Imran Rashid <irashid@cloudera.com> wrote:
> 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 <irashid@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 <pwendell@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 <sowen@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 <irashid@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-unsubscribe@spark.apache.org
>>> > For additional commands, e-mail: dev-help@spark.apache.org
>>> >
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@spark.apache.org
For additional commands, e-mail: dev-help@spark.apache.org


Mime
View raw message