java enums more compact, flexible and obvious than scala's equivalent?

to add an ordering: List(yourcaseclassA(1), yourcaseclassB(23),yourcaseclassC(17),...)

or:

yourCaseClass(num:Int, ord:Int = OrderingAtomicObject.nextInt)

or you could use an implicit conversion to add logic to your simple scala enumeration.

Am 26.06.2011 20:31, schrieb mond ray mond:

Sorry for what might seem like a trolling subject line, but this is a bit of a shocker since I usually find elegance in Scala rather than Java.
I am dealing with some legacy record layouts and in Java I have something like this
public enum FlatFileHeaderMapping {
   FIELD1(1),    FIELD2(5),    // And loads more, elided for the sake of (your) sanity    FIELDN(4)
   public final int fieldSize;
    private FlatFileHeaderMapping(final int fieldSize) {         this.fieldSize = fieldSize;    } }
which I can then use to place each line into a map:
    public ProcessLegacyRecord(final String inputString) {
        // Specify LinkedHashMap to retain insertion order         LinkedHashMap<FlatFileHeaderMapping, String> headerValuesMap;
        headerValuesMap = new LinkedHashMap<FlatFileHeaderMapping, String>();         int currPos = 0;         for (FlatFileHeaderMapping m : FlatFileHeaderMapping.values()) {             int endPos = currPos + m.fieldSize;             String HeaderValue = inputString.substring(currPos, endPos);             headerValuesMap.put(m, HeaderValue);             currPos = endPos;         }     }
and later access the keys in the map via this enum:
        String field1 = headerValuesMap.get(FlatFileHeaderMapping.FIELD1);
Enumeration does not have these qualities as far as I can see, and case classes are not ordered like the enum values - so cannot be used to match a record layout as shown above. At least not without the support of an ordered collection.
I could be missing something obvious, hence the question!
Or please feel free to tear up the enum aspect and suggest a more functional, Scala-esque way to deal with fixed length inputs in a type safe / symbolic / elegant way!
Thanks
Ray
PS I also posted a shorter form of this question to SO http://stackoverflow.com/questions/6473445/how-do-i-create-an-enum-in-scala-that-has-an-extra-field

I see where you're going on the case class but doesn't this result in
a huge number of class definitions - 1 per field?

Could you flesh out the implicit idea a little more? I would like to
grok the magic ;-)

Thanks

Ray

On Sunday, 26 June 2011, HamsterofDeath wrote:
>
>
>
>
>
>
>
> to add an ordering: List(yourcaseclassA(1),
> yourcaseclassB(23),yourcaseclassC(17),...)
>
> or:
>
> yourCaseClass(num:Int, ord:Int = OrderingAtomicObject.nextInt)
>
> or you could use an implicit conversion to add logic to your simple
> scala enumeration.
>
> Am 26.06.2011 20:31, schrieb mond ray mond:
>
>
> Sorry for what might seem like a trolling subject line, but
> this is a bit of a shocker since I usually find elegance in
> Scala rather than Java.
>
>
> I am dealing with some legacy record layouts and in Java I
> have something like this
>
>
> public enum FlatFileHeaderMapping {
>
>
>    FIELD1(1),
>    FIELD2(5),
>    // And loads more, elided for the sake of (your) sanity
>    FIELDN(4)
>
>
>    public final int fieldSize;
>
>
>     private FlatFileHeaderMapping(final int fieldSize) {
>         this.fieldSize = fieldSize;
>    }
> }
>
>
> which I can then use to place each line into a map:
>
>
>     public ProcessLegacyRecord(final String inputString) {
>
>
>         // Specify LinkedHashMap to retain insertion order
>         LinkedHashMap
> headerValuesMap;
>
>
>         headerValuesMap = new
> LinkedHashMap();
>         int currPos = 0;
>         for (FlatFileHeaderMapping m :
> FlatFileHeaderMapping.values()) {
>             int endPos = currPos + m.fieldSize;
>             String HeaderValue =
> inputString.substring(currPos, endPos);
>             headerValuesMap.put(m, HeaderValue);
>             currPos = endPos;
>         }
>     }
>
>
> and later access the keys in the map via this enum:
>
>
>         String field1 =
> headerValuesMap.get(FlatFileHeaderMapping.FIELD1);
>
>
> Enumeration does not have these qualities as far as I can
> see, and case classes are not ordered like the enum values - so
> cannot be used to match a record layout as shown above. At least
> not without the support of an ordered collection.
>
>
> I could be missing something obvious, hence the question!
>
>
> Or please feel free to tear up the enum aspect and suggest a
> more functional, Scala-esque way to deal with fixed length
> inputs in a type safe / symbolic / elegant way!
>
>
> Thanks
>
>
> Ray
>
>
> PS I also posted a shorter form of this question to SO
> http://stackoverflow.com/questions/6473445/how-do-i-create-an-enum-in-sc...
>
>
>
>
>
>

implicit def enableSomeMethods(yourenumvalue:YourEnumType) = new {
//your methods here. if you need to fake an attribute, you can do:
def getAttrib = yourenumvalue match {
case a => 1
case b => 25
//and so on
}
}

i don't know how much you know about implicit conversions, but this
piece of code can be imported and then you can do:
yourEnumValue.yourMethodDeclaredInThePartAbove

(this email has been written with the screen being behind my back, so i
didn not see much. going to plac alice: madness returns on my
3dprojector (or whatever it's called in english)

it'll be slower than the case class solution, but if that's not a
problem, go ahead.

Am 26.06.2011 21:09, schrieb mond ray:

> I see where you're going on the case class but doesn't this result in
> a huge number of class definitions - 1 per field?
>
> Could you flesh out the implicit idea a little more? I would like to
> grok the magic ;-)
>
> Thanks
>
> Ray
>
> On Sunday, 26 June 2011, HamsterofDeath wrote:
>>
>>
>>
>>
>>
>>
>> to add an ordering: List(yourcaseclassA(1),
>> yourcaseclassB(23),yourcaseclassC(17),...)
>>
>> or:
>>
>> yourCaseClass(num:Int, ord:Int = OrderingAtomicObject.nextInt)
>>
>> or you could use an implicit conversion to add logic to your simple
>> scala enumeration.
>>
>> Am 26.06.2011 20:31, schrieb mond ray mond:
>>
>>
>> Sorry for what might seem like a trolling subject line, but
>> this is a bit of a shocker since I usually find elegance in
>> Scala rather than Java.
>>
>>
>> I am dealing with some legacy record layouts and in Java I
>> have something like this
>>
>>
>> public enum FlatFileHeaderMapping {
>>
>>
>> FIELD1(1),
>> FIELD2(5),
>> // And loads more, elided for the sake of (your) sanity
>> FIELDN(4)
>>
>>
>> public final int fieldSize;
>>
>>
>> private FlatFileHeaderMapping(final int fieldSize) {
>> this.fieldSize = fieldSize;
>> }
>> }
>>
>>
>> which I can then use to place each line into a map:
>>
>>
>> public ProcessLegacyRecord(final String inputString) {
>>
>>
>> // Specify LinkedHashMap to retain insertion order
>> LinkedHashMap
>> headerValuesMap;
>>
>>
>> headerValuesMap = new
>> LinkedHashMap();
>> int currPos = 0;
>> for (FlatFileHeaderMapping m :
>> FlatFileHeaderMapping.values()) {
>> int endPos = currPos + m.fieldSize;
>> String HeaderValue =
>> inputString.substring(currPos, endPos);
>> headerValuesMap.put(m, HeaderValue);
>> currPos = endPos;
>> }
>> }
>>
>>
>> and later access the keys in the map via this enum:
>>
>>
>> String field1 =
>> headerValuesMap.get(FlatFileHeaderMapping.FIELD1);
>>
>>
>> Enumeration does not have these qualities as far as I can
>> see, and case classes are not ordered like the enum values - so
>> cannot be used to match a record layout as shown above. At least
>> not without the support of an ordered collection.
>>
>>
>> I could be missing something obvious, hence the question!
>>
>>
>> Or please feel free to tear up the enum aspect and suggest a
>> more functional, Scala-esque way to deal with fixed length
>> inputs in a type safe / symbolic / elegant way!
>>
>>
>> Thanks
>>
>>
>> Ray
>>
>>
>> PS I also posted a shorter form of this question to SO
>> http://stackoverflow.com/questions/6473445/how-do-i-create-an-enum-in-sc...
>>
>>
>>
>>
>>
>>

Am 26.06.2011 21:09, schrieb mond ray:
> I see where you're going on the case class but doesn't this result in
> a huge number of class definitions - 1 per field?

not necessarily.
val first = youronlycaseclass(1)
val second = youronlycaseclass(4)

List(first, second)
> Could you flesh out the implicit idea a little more? I would like to
> grok the magic ;-)
>
> Thanks
>
> Ray
>
> On Sunday, 26 June 2011, HamsterofDeath wrote:
>>
>>
>>
>>
>>
>>
>> to add an ordering: List(yourcaseclassA(1),
>> yourcaseclassB(23),yourcaseclassC(17),...)
>>
>> or:
>>
>> yourCaseClass(num:Int, ord:Int = OrderingAtomicObject.nextInt)
>>
>> or you could use an implicit conversion to add logic to your simple
>> scala enumeration.
>>
>> Am 26.06.2011 20:31, schrieb mond ray mond:
>>
>>
>> Sorry for what might seem like a trolling subject line, but
>> this is a bit of a shocker since I usually find elegance in
>> Scala rather than Java.
>>
>>
>> I am dealing with some legacy record layouts and in Java I
>> have something like this
>>
>>
>> public enum FlatFileHeaderMapping {
>>
>>
>> FIELD1(1),
>> FIELD2(5),
>> // And loads more, elided for the sake of (your) sanity
>> FIELDN(4)
>>
>>
>> public final int fieldSize;
>>
>>
>> private FlatFileHeaderMapping(final int fieldSize) {
>> this.fieldSize = fieldSize;
>> }
>> }
>>
>>
>> which I can then use to place each line into a map:
>>
>>
>> public ProcessLegacyRecord(final String inputString) {
>>
>>
>> // Specify LinkedHashMap to retain insertion order
>> LinkedHashMap
>> headerValuesMap;
>>
>>
>> headerValuesMap = new
>> LinkedHashMap();
>> int currPos = 0;
>> for (FlatFileHeaderMapping m :
>> FlatFileHeaderMapping.values()) {
>> int endPos = currPos + m.fieldSize;
>> String HeaderValue =
>> inputString.substring(currPos, endPos);
>> headerValuesMap.put(m, HeaderValue);
>> currPos = endPos;
>> }
>> }
>>
>>
>> and later access the keys in the map via this enum:
>>
>>
>> String field1 =
>> headerValuesMap.get(FlatFileHeaderMapping.FIELD1);
>>
>>
>> Enumeration does not have these qualities as far as I can
>> see, and case classes are not ordered like the enum values - so
>> cannot be used to match a record layout as shown above. At least
>> not without the support of an ordered collection.
>>
>>
>> I could be missing something obvious, hence the question!
>>
>>
>> Or please feel free to tear up the enum aspect and suggest a
>> more functional, Scala-esque way to deal with fixed length
>> inputs in a type safe / symbolic / elegant way!
>>
>>
>> Thanks
>>
>>
>> Ray
>>
>>
>> PS I also posted a shorter form of this question to SO
>> http://stackoverflow.com/questions/6473445/how-do-i-create-an-enum-in-sc...
>>
>>
>>
>>
>>
>>

But don't I then I lose the symbolic style name that the enum provides... I only have the vals first and second, which I can't see how I would use them as keys to access the map as shown in may sample.  I might blush to see the answer but is it possible to limit the scope of the names first, second, etc... like they are in the enum version?
Thanks for your patience!
Ray

On 26 June 2011 21:18, HamsterofDeath <h-star@gmx.de> wrote:

Am 26.06.2011 21:09, schrieb mond ray:
> I see where you're going on the case class but doesn't this result in
> a huge number of class definitions - 1 per field?

not necessarily.
val first = youronlycaseclass(1)
val second = youronlycaseclass(4)

List(first, second)
> Could you flesh out the implicit idea a little more?  I would like to
> grok the magic ;-)
>
> Thanks
>
> Ray
>
> On Sunday, 26 June 2011, HamsterofDeath <h-star@gmx.de> wrote:
>>
>>
>>
>>
>>
>>
>>     to add an ordering: List(yourcaseclassA(1),
>>     yourcaseclassB(23),yourcaseclassC(17),...)
>>
>>     or:
>>
>>     yourCaseClass(num:Int, ord:Int = OrderingAtomicObject.nextInt)
>>
>>     or you could use an implicit conversion to add logic to your simple
>>     scala enumeration.
>>
>>     Am 26.06.2011 20:31, schrieb mond ray mond:
>>
>>
>>       Sorry for what might seem like a trolling subject line, but
>>         this is a bit of a shocker since I usually find elegance in
>>         Scala rather than Java.
>>
>>
>>       I am dealing with some legacy record layouts and in Java I
>>         have something like this
>>
>>
>>       public enum FlatFileHeaderMapping {
>>
>>
>>          FIELD1(1),
>>          FIELD2(5),
>>          // And loads more, elided for the sake of (your) sanity
>>          FIELDN(4)
>>
>>
>>          public final int fieldSize;
>>
>>
>>           private FlatFileHeaderMapping(final int fieldSize) {
>>               this.fieldSize = fieldSize;
>>          }
>>       }
>>
>>
>>       which I can then use to place each line into a map:
>>
>>
>>           public ProcessLegacyRecord(final String inputString) {
>>
>>
>>               // Specify LinkedHashMap to retain insertion order
>>               LinkedHashMap<FlatFileHeaderMapping, String>
>>         headerValuesMap;
>>
>>
>>               headerValuesMap = new
>>         LinkedHashMap<FlatFileHeaderMapping, String>();
>>               int currPos = 0;
>>               for (FlatFileHeaderMapping m :
>>         FlatFileHeaderMapping.values()) {
>>                   int endPos = currPos + m.fieldSize;
>>                   String HeaderValue =
>>         inputString.substring(currPos, endPos);
>>                   headerValuesMap.put(m, HeaderValue);
>>                   currPos = endPos;
>>               }
>>           }
>>
>>
>>       and later access the keys in the map via this enum:
>>
>>
>>               String field1 =
>>         headerValuesMap.get(FlatFileHeaderMapping.FIELD1);
>>
>>
>>       Enumeration does not have these qualities as far as I can
>>         see, and case classes are not ordered like the enum values - so
>>         cannot be used to match a record layout as shown above. At least
>>         not without the support of an ordered collection.
>>
>>
>>       I could be missing something obvious, hence the question!
>>
>>
>>       Or please feel free to tear up the enum aspect and suggest a
>>         more functional, Scala-esque way to deal with fixed length
>>         inputs in a type safe / symbolic / elegant way!
>>
>>
>>       Thanks
>>
>>
>>       Ray
>>
>>
>>       PS I also posted a shorter form of this question to SO
>> http://stackoverflow.com/questions/6473445/how-do-i-create-an-enum-in-scala-that-has-an-extra-field
>>
>>
>>
>>
>>
>>

On Sunday 26 June 2011, mond ray wrote:
> I see where you're going on the case class but doesn't this result in
> a huge number of class definitions - 1 per field?

If you're worried about JVM-level class proliferation, Scala's not the
language for you! Every closure / function literal in Scala is
implemented as a class.

> Could you flesh out the implicit idea a little more? I would like to
> grok the magic ;-)
>
> Thanks
>
> Ray

Randall Schulz

I was thinking about classes visible in scala. This feels like you
semi-flamed me which ain't friendly Randall.

On Sunday, 26 June 2011, Randall R Schulz wrote:
> On Sunday 26 June 2011, mond ray wrote:
>> I see where you're going on the case class but doesn't this result in
>> a huge number of class definitions - 1 per field?
>
> If you're worried about JVM-level class proliferation, Scala's not the
> language for you! Every closure / function literal in Scala is
> implemented as a class.
>
>
>> Could you flesh out the implicit idea a little more?  I would like to
>> grok the magic ;-)
>>
>> Thanks
>>
>> Ray
>
>
> Randall Schulz
>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

type Three = Option[Unit]
type FlatFileHeaderMapping = (Three /* want more? */, Int)

Syntactic compactness is chronically overrated. You want computational
compactness.

On 27/06/11 04:31, mond ray mond wrote:
> Sorry for what might seem like a trolling subject line, but this is
> a bit of a shocker since I usually find elegance in Scala rather
> than Java.
>
> I am dealing with some legacy record layouts and in Java I have
> something like this
>
> public enum FlatFileHeaderMapping {
>
> FIELD1(1), FIELD2(5), // And loads more, elided for the sake of
> (your) sanity FIELDN(4)
>
> public final int fieldSize;
>
> private FlatFileHeaderMapping(final int fieldSize) { this.fieldSize
> = fieldSize; } }
>
> which I can then use to place each line into a map:
>
> public ProcessLegacyRecord(final String inputString) {
>
> // Specify LinkedHashMap to retain insertion order
> LinkedHashMap headerValuesMap;
>
> headerValuesMap = new LinkedHashMap String>(); int currPos = 0; for (FlatFileHeaderMapping m :
> FlatFileHeaderMapping.values()) { int endPos = currPos +
> m.fieldSize; String HeaderValue = inputString.substring(currPos,
> endPos); headerValuesMap.put(m, HeaderValue); currPos = endPos; }
> }
>
> and later access the keys in the map via this enum:
>
> String field1 = headerValuesMap.get(FlatFileHeaderMapping.FIELD1);
>
> Enumeration does not have these qualities as far as I can see, and
> case classes are not ordered like the enum values - so cannot be
> used to match a record layout as shown above. At least not without
> the support of an ordered collection.
>
> I could be missing something obvious, hence the question!
>
> Or please feel free to tear up the enum aspect and suggest a more
> functional, Scala-esque way to deal with fixed length inputs in a
> type safe / symbolic / elegant way!
>
> Thanks
>
> Ray
>
> PS I also posted a shorter form of this question to SO
> http://stackoverflow.com/questions/6473445/how-do-i-create-an-enum-in-sc...
>

- --
>
Tony Morris
http://tmorris.net/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4HriMACgkQmnpgrYe6r63IQQCfauE6von3YqeFsvcscQnhEGSx
2LgAnRNdE8UJznf/UAF2gR9kTmtT/OUC
=V7No
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I had a similar problem, and was similarly surprised. Fortunately
Scala's minimal enums are the only instance I've encountered where Scala
is less capable than Java.

I shamelessly stole the idea from here:

http://stackoverflow.com/questions/1898932/case-classes-vs-enumerations-...

to make:

//Named SEnum to avoid clashing with java.lang.Enum

trait SEnum[T] extends scala.Iterable[T] {
trait Value extends Ordered[Value] { self: T =>
constants += this

val name: String

override def toString = name

val ordinal = nextOrdinal

override def compare(other: Value) = this.ordinal -
other.asInstanceOf[Value].ordinal
}

private var ordinal = 0

private var nextOrdinal = {
val current = ordinal

ordinal += 1

current
}

private val constants = new scala.collection.mutable.ArrayBuffer[T]

def values = constants.toSeq

override def iterator = values.iterator
}

There's an ordinal field (I don't use it much, but it gives an
ordering), a name, and you can add all the methods and fields that you
want. You can also extend and mix in anything you want. I like this
because enums are a nice way to represent strategies. (I know there are
other ways to do that in Scala.) hashCode and equals methods might be
nice, but reference equality works for my use case.

I use the SEnum trait like this. It's a little verbose, but it gets
back most of Java's functionality.

final class Field private (val name: String,
val size: Int) extends Field.Value

object Field extends SEnum[Field] {
val Field1 = new Field("Field1", 1)
val Field2 = new Field("Field2", 5)
//...
val FieldN = new Field("FieldN", 4)
}

Field.values.foreach(println)

One wart is the requirement to give each enum constant an explicit name.
As the Stackoverflow post describes, useing case objects instead of
vals can get around this, but since objects are lazy, your Field.values
sequence may not have anything in it if the constants are objects.

On 06/26/2011 02:31 PM, mond ray mond wrote:
> Sorry for what might seem like a trolling subject line, but this is a
> bit of a shocker since I usually find elegance in Scala rather than Java.
>
> I am dealing with some legacy record layouts and in Java I have
> something like this
>
> public enum FlatFileHeaderMapping {
>
> FIELD1(1),
> FIELD2(5),
> // And loads more, elided for the sake of (your) sanity
> FIELDN(4)
>
> public final int fieldSize;
>
> private FlatFileHeaderMapping(final int fieldSize) {
> this.fieldSize = fieldSize;
> }
> }
>
> which I can then use to place each line into a map:
>
> public ProcessLegacyRecord(final String inputString) {
>
> // Specify LinkedHashMap to retain insertion order
> LinkedHashMap headerValuesMap;
>
> headerValuesMap = new LinkedHashMap String>();
> int currPos = 0;
> for (FlatFileHeaderMapping m : FlatFileHeaderMapping.values()) {
> int endPos = currPos + m.fieldSize;
> String HeaderValue = inputString.substring(currPos, endPos);
> headerValuesMap.put(m, HeaderValue);
> currPos = endPos;
> }
> }
>
> and later access the keys in the map via this enum:
>
> String field1 = headerValuesMap.get(FlatFileHeaderMapping.FIELD1);
>
> Enumeration does not have these qualities as far as I can see, and case
> classes are not ordered like the enum values - so cannot be used to
> match a record layout as shown above. At least not without the support
> of an ordered collection.
>
> I could be missing something obvious, hence the question!
>
> Or please feel free to tear up the enum aspect and suggest a more
> functional, Scala-esque way to deal with fixed length inputs in a type
> safe / symbolic / elegant way!
>
> Thanks
>
> Ray
>
> PS I also posted a shorter form of this question to SO
> http://stackoverflow.com/questions/6473445/how-do-i-create-an-enum-in-sc...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAk4Hrl0ACgkQ0GFaTS4nYxtdxgCgjyX7kBwoXuk0+d/HwhE7ndwJ
0pwAnjVKiDtL2ic6V4n1lXd2n4/nh62a
=GOLF
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

type Three = Option[Boolean] // correction

On 27/06/11 08:09, Tony Morris wrote:
>
> type Three = Option[Unit] type FlatFileHeaderMapping = (Three /*
> want more? */, Int)
>
> Syntactic compactness is chronically overrated. You want
> computational compactness.
>
> On 27/06/11 04:31, mond ray mond wrote:
>> Sorry for what might seem like a trolling subject line, but this
>> is a bit of a shocker since I usually find elegance in Scala
>> rather than Java.
>
>> I am dealing with some legacy record layouts and in Java I have
>> something like this
>
>> public enum FlatFileHeaderMapping {
>
>> FIELD1(1), FIELD2(5), // And loads more, elided for the sake of
>> (your) sanity FIELDN(4)
>
>> public final int fieldSize;
>
>> private FlatFileHeaderMapping(final int fieldSize) {
>> this.fieldSize = fieldSize; } }
>
>> which I can then use to place each line into a map:
>
>> public ProcessLegacyRecord(final String inputString) {
>
>> // Specify LinkedHashMap to retain insertion order
>> LinkedHashMap<FlatFileHeaderMapping, String> headerValuesMap;
>
>> headerValuesMap = new LinkedHashMap<FlatFileHeaderMapping,
>> String>(); int currPos = 0; for (FlatFileHeaderMapping m :
>> FlatFileHeaderMapping.values()) { int endPos = currPos +
>> m.fieldSize; String HeaderValue = inputString.substring(currPos,
>> endPos); headerValuesMap.put(m, HeaderValue); currPos = endPos;
>> } }
>
>> and later access the keys in the map via this enum:
>
>> String field1 =
>> headerValuesMap.get(FlatFileHeaderMapping.FIELD1);
>
>> Enumeration does not have these qualities as far as I can see,
>> and case classes are not ordered like the enum values - so
>> cannot be used to match a record layout as shown above. At least
>> not without the support of an ordered collection.
>
>> I could be missing something obvious, hence the question!
>
>> Or please feel free to tear up the enum aspect and suggest a more
>> functional, Scala-esque way to deal with fixed length inputs in a
>> type safe / symbolic / elegant way!
>
>> Thanks
>
>> Ray
>
>> PS I also posted a shorter form of this question to SO
>>
> http://stackoverflow.com/questions/6473445/how-do-i-create-an-enum-in-scala-that-has-an-extra-field
>
>
>

- --
>
>
Tony Morris
http://tmorris.net/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4HsKEACgkQmnpgrYe6r61bGACfWbJfwlgSlQ6nSd/8xRk/F3Ne
OuoAnR3Bgn8HUU6o2RL2gmb2JiKFnMu9
=udBV
-----END PGP SIGNATURE-----

I took a look at the stackoverflow posting mentioned above. I've also taken to using case objects for my Enums, though not nearly in as sophisticated a manner--but then, my needs haven't yet been that complex.
But all of this different experimentation that people are doing around how to do enums is making one thing blindingly clear to me:
SCALA NEEDS A REAL ENUM TYPE.
The fact that so many people are trying so many different things is clear evidence that the current "solution" is not that as far as many users are concerned. In addition, it adds a (moderately high--I have to look up how to define Enums every time I do it the "official" way) hurdle for Java programmers to clear when they start with Scala, and that hurdle comes pretty quickly--after all, enums are really quite basic.
While I respect the desire of the Scala team to keep the language as conceptually lean as possible, I think it is time to at least talk about adding in a genuine enumerated type facility, given that the experimentation people are doing indicates the recommended solution is not satisfactory.
Comments?
Thanks,Ken

There will always be several (infinite) ways to define an algebraic data
type, even in Java:
interface Boolean { X ifelse(X t, X f); }

No, it isn't blindingly clear. It's a distraction.

On 27/06/11 08:40, Ken McDonald wrote:
> I took a look at the stackoverflow posting mentioned above. I've also
> taken to using case objects for my Enums, though not nearly in as
> sophisticated a manner--but then, my needs haven't yet been that complex.
>
> But all of this different experimentation that people are doing around
> how to do enums is making one thing blindingly clear to me:
>
> SCALA NEEDS A REAL ENUM TYPE.
>
> The fact that so many people are trying so many different things is
> clear evidence that the current "solution" is not that as far as many
> users are concerned. In addition, it adds a (moderately high--I have
> to look up how to define Enums every time I do it the "official" way)
> hurdle for Java programmers to clear when they start with Scala, and
> that hurdle comes pretty quickly--after all, enums are really quite basic.
>
> While I respect the desire of the Scala team to keep the language as
> conceptually lean as possible, I think it is time to at least talk
> about adding in a genuine enumerated type facility, given that the
> experimentation people are doing indicates the recommended solution is
> not satisfactory.
>
> Comments?
>
> Thanks,
> Ken

I'm pretty sure no-one has confiscated your java compiler. If you
desperately, desperately want java enums, make them in java.

Problem solved?

On Mon, Jun 27, 2011 at 12:22 AM, Tony Morris wrote:
> There will always be several (infinite) ways to define an algebraic data
> type, even in Java:
> interface Boolean { X ifelse(X t, X f); }
>
> No, it isn't blindingly clear. It's a distraction.
>
> On 27/06/11 08:40, Ken McDonald wrote:
>> I took a look at the stackoverflow posting mentioned above. I've also
>> taken to using case objects for my Enums, though not nearly in as
>> sophisticated a manner--but then, my needs haven't yet been that complex.
>>
>> But all of this different experimentation that people are doing around
>> how to do enums is making one thing blindingly clear to me:
>>
>> SCALA NEEDS A REAL ENUM TYPE.
>>
>> The fact that so many people are trying so many different things is
>> clear evidence that the current "solution" is not that as far as many
>> users are concerned. In addition, it adds a (moderately high--I have
>> to look up how to define Enums every time I do it the "official" way)
>> hurdle for Java programmers to clear when they start with Scala, and
>> that hurdle comes pretty quickly--after all, enums are really quite basic.
>>
>> While I respect the desire of the Scala team to keep the language as
>> conceptually lean as possible, I think it is time to at least talk
>> about adding in a genuine enumerated type facility, given that the
>> experimentation people are doing indicates the recommended solution is
>> not satisfactory.
>>
>> Comments?
>>
>> Thanks,
>> Ken
>
>
> --
> Tony Morris
> http://tmorris.net/
>
>
>

The problem is disproportionate attention to syntactic/aesthetic desires
on arbitrary biases. Coaching out of the bubble is a tough task.

On 27/06/11 10:03, Alec Zorab wrote:
> I'm pretty sure no-one has confiscated your java compiler. If you
> desperately, desperately want java enums, make them in java.
>
> Problem solved?
>
> On Mon, Jun 27, 2011 at 12:22 AM, Tony Morris wrote:
>> There will always be several (infinite) ways to define an algebraic data
>> type, even in Java:
>> interface Boolean { X ifelse(X t, X f); }
>>
>> No, it isn't blindingly clear. It's a distraction.
>>
>> On 27/06/11 08:40, Ken McDonald wrote:
>>> I took a look at the stackoverflow posting mentioned above. I've also
>>> taken to using case objects for my Enums, though not nearly in as
>>> sophisticated a manner--but then, my needs haven't yet been that complex.
>>>
>>> But all of this different experimentation that people are doing around
>>> how to do enums is making one thing blindingly clear to me:
>>>
>>> SCALA NEEDS A REAL ENUM TYPE.
>>>
>>> The fact that so many people are trying so many different things is
>>> clear evidence that the current "solution" is not that as far as many
>>> users are concerned. In addition, it adds a (moderately high--I have
>>> to look up how to define Enums every time I do it the "official" way)
>>> hurdle for Java programmers to clear when they start with Scala, and
>>> that hurdle comes pretty quickly--after all, enums are really quite basic.
>>>
>>> While I respect the desire of the Scala team to keep the language as
>>> conceptually lean as possible, I think it is time to at least talk
>>> about adding in a genuine enumerated type facility, given that the
>>> experimentation people are doing indicates the recommended solution is
>>> not satisfactory.
>>>
>>> Comments?
>>>
>>> Thanks,
>>> Ken
>>
>> --
>> Tony Morris
>> http://tmorris.net/
>>
>>
>>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

This isn't a bad solution, especially for simple cases. Using Java
enums from Scala works quite well. I got away from that approach due to
the problems I had with the Eclipse Scala plugin and mixed Scala/Java
projects. The Scala plugin is much happier with a 100% Scala project,
which is why I started looking for an all-Scala solution.

On 06/26/2011 08:03 PM, Alec Zorab wrote:
> I'm pretty sure no-one has confiscated your java compiler. If you
> desperately, desperately want java enums, make them in java.
>
> Problem solved?
>
> On Mon, Jun 27, 2011 at 12:22 AM, Tony Morris wrote:
>> There will always be several (infinite) ways to define an algebraic data
>> type, even in Java:
>> interface Boolean { X ifelse(X t, X f); }
>>
>> No, it isn't blindingly clear. It's a distraction.
>>
>> On 27/06/11 08:40, Ken McDonald wrote:
>>> I took a look at the stackoverflow posting mentioned above. I've also
>>> taken to using case objects for my Enums, though not nearly in as
>>> sophisticated a manner--but then, my needs haven't yet been that complex.
>>>
>>> But all of this different experimentation that people are doing around
>>> how to do enums is making one thing blindingly clear to me:
>>>
>>> SCALA NEEDS A REAL ENUM TYPE.
>>>
>>> The fact that so many people are trying so many different things is
>>> clear evidence that the current "solution" is not that as far as many
>>> users are concerned. In addition, it adds a (moderately high--I have
>>> to look up how to define Enums every time I do it the "official" way)
>>> hurdle for Java programmers to clear when they start with Scala, and
>>> that hurdle comes pretty quickly--after all, enums are really quite basic.
>>>
>>> While I respect the desire of the Scala team to keep the language as
>>> conceptually lean as possible, I think it is time to at least talk
>>> about adding in a genuine enumerated type facility, given that the
>>> experimentation people are doing indicates the recommended solution is
>>> not satisfactory.
>>>
>>> Comments?
>>>
>>> Thanks,
>>> Ken
>>
>>
>> --
>> Tony Morris
>> http://tmorris.net/
>>
>>
>>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAk4H6gwACgkQ0GFaTS4nYxs8pgCfRapIp8+undCYAE9Wn1L2X5gq
kasAnikHDTrzTFNHTVzTP7IvgE5Cs/8S
=WcEb
-----END PGP SIGNATURE-----

Indeed Alec, though that's a little trite, eh?
Wouldn't it also be nice to have a Scala solution that is clear, simple and at least as usable as the Java type?  If it's better done with some idiomatic Scala, then that's fine.
I know it must be torture Tony, but it's a bit much to ask that I (and many other Java migrants) need to go away and study the theory of algebraic data types before making any further meaningful comment.  
Shouldn't the smart folks be making the appropriate idiomatic usage accessible to the rest of us?
Best regards
Ray

On 27 June 2011 02:03, Alec Zorab <aleczorab@googlemail.com> wrote:

I'm pretty sure no-one has confiscated your java compiler. If you
desperately, desperately want java enums, make them in java.

Problem solved?

On Mon, Jun 27, 2011 at 12:22 AM, Tony Morris <tonymorris@gmail.com> wrote:
> There will always be several (infinite) ways to define an algebraic data
> type, even in Java:
> interface Boolean { <X> X ifelse(X t, X f); }
>
> No, it isn't blindingly clear. It's a distraction.
>
> On 27/06/11 08:40, Ken McDonald wrote:
>> I took a look at the stackoverflow posting mentioned above. I've also
>> taken to using case objects for my Enums, though not nearly in as
>> sophisticated a manner--but then, my needs haven't yet been that complex.
>>
>> But all of this different experimentation that people are doing around
>> how to do enums is making one thing blindingly clear to me:
>>
>> SCALA NEEDS A REAL ENUM TYPE.
>>
>> The fact that so many people are trying so many different things is
>> clear evidence that the current "solution" is not that as far as many
>> users are concerned. In addition, it adds a (moderately high--I have
>> to look up how to define Enums every time I do it the "official" way)
>> hurdle for Java programmers to clear when they start with Scala, and
>> that hurdle comes pretty quickly--after all, enums are really quite basic.
>>
>> While I respect the desire of the Scala team to keep the language as
>> conceptually lean as possible, I think it is time to at least talk
>> about adding in a genuine enumerated type facility, given that the
>> experimentation people are doing indicates the recommended solution is
>> not satisfactory.
>>
>> Comments?
>>
>> Thanks,
>> Ken
>
>
> --
> Tony Morris
> http://tmorris.net/
>
>
>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 27/06/11 19:29, mond ray wrote:
> Indeed Alec, though that's a little trite, eh?
>
> Wouldn't it also be nice to have a Scala solution that is clear,
> simple and at least as usable as the Java type? If it's better
> done with some idiomatic Scala, then that's fine.
>
> I know it must be torture Tony, but it's a bit much to ask that I
> (and many other Java migrants) need to go away and study the
> theory of algebraic data types before making any further
> meaningful comment.

I'm not sure why you ask that, but no, it's not a bit much to ask. Why
should one not understand algebra before expecting one's comment to be
taken seriously on algebra? That only makes sense to me. Besides,
learning is fun.

We see this issue every few weeks by the way.

>
> Shouldn't the smart folks be making the appropriate idiomatic usage
> accessible to the rest of us?
There is no "idiomatic usage." This is simply an exhibition of an
arbitrary bias.

Always happy to teach algebra[ic data types], any time and (almost)
any forum.


- --
Tony Morris
http://tmorris.net/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4ITxYACgkQmnpgrYe6r60uPgCglGLFWWXEg+1fPxBB/MOM5eMZ
3SsAnjkyZ82XAfEWIM0EOzuruWK2FQYX
=eLSM
-----END PGP SIGNATURE-----

Why's it trite? you're trying to shoehorn a java idiom into scala and
then complaining that scala doesn't support it. There is already a
well defined and widely used system for java idioms (it's called
"java").

No-one is stopping you using it.

On Mon, Jun 27, 2011 at 10:36 AM, Tony Morris wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 27/06/11 19:29, mond ray wrote:
>> Indeed Alec, though that's a little trite, eh?
>>
>> Wouldn't it also be nice to have a Scala solution that is clear,
>> simple and at least as usable as the Java type? If it's better
>> done with some idiomatic Scala, then that's fine.
>>
>> I know it must be torture Tony, but it's a bit much to ask that I
>> (and many other Java migrants) need to go away and study the
>> theory of algebraic data types before making any further
>> meaningful comment.
>
> I'm not sure why you ask that, but no, it's not a bit much to ask. Why
> should one not understand algebra before expecting one's comment to be
> taken seriously on algebra? That only makes sense to me. Besides,
> learning is fun.
>
> We see this issue every few weeks by the way.
>
>>
>> Shouldn't the smart folks be making the appropriate idiomatic usage
>> accessible to the rest of us?
> There is no "idiomatic usage." This is simply an exhibition of an
> arbitrary bias.
>
> Always happy to teach algebra[ic data types], any time and (almost)
> any forum.
>
>
> - --
> Tony Morris
> http://tmorris.net/
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk4ITxYACgkQmnpgrYe6r60uPgCglGLFWWXEg+1fPxBB/MOM5eMZ
> 3SsAnjkyZ82XAfEWIM0EOzuruWK2FQYX
> =eLSM
> -----END PGP SIGNATURE-----
>
>

We see this issue every few weeks by the way.

Yes, which tells us one of: we don't have the right documentation; there is a genuine issue that needs addressing; the 'wrong' people are trying to use scala. As scala is a general purpose programming that has every intention of being main-stream, I think that rules the 3rd option out. I don't personally find responses along the lines of, "learn category theory" and, "you should understand algebra" either leads anyone towards enlightenment or welcomes them into the scala community.
Matthew

- --
Tony Morris
http://tmorris.net/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4ITxYACgkQmnpgrYe6r60uPgCglGLFWWXEg+1fPxBB/MOM5eMZ
3SsAnjkyZ82XAfEWIM0EOzuruWK2FQYX
=eLSM
-----END PGP SIGNATURE-----

--
Dr Matthew PocockVisitor, School of Computing Science, Newcastle Universitymailto: turingatemyhamster@gmail.com gchat: turingatemyhamster@gmail.commsn: matthew_pocock@yahoo.co.uk irc.freenode.net: drdozer(0191) 2566550

As I mentioned directly to Ray earlier, I think this stems from the
fact that java enums are very odd little beasts which people have
built very language-specific patterns around. Either Java enums get
added to the language (which I think is bad, because they're not very
general at all) or people just use Java to generate their enums (which
lets fans of the pattern carry on using it) or people use case
objects, as is generally considered idiomatic.

I personally have never felt the need to use an enum since I moved
from C, so I can't personally say which is preferable.

Regards

On Mon, Jun 27, 2011 at 1:25 PM, Matthew Pocock
wrote:
>>
>> We see this issue every few weeks by the way.
>
> Yes, which tells us one of: we don't have the right documentation; there is
> a genuine issue that needs addressing; the 'wrong' people are trying to use
> scala. As scala is a general purpose programming that has every intention of
> being main-stream, I think that rules the 3rd option out. I don't personally
> find responses along the lines of, "learn category theory" and, "you should
> understand algebra" either leads anyone towards enlightenment or welcomes
> them into the scala community.
> Matthew
>>
>>
>> - --
>> Tony Morris
>> http://tmorris.net/
>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.10 (GNU/Linux)
>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>>
>> iEYEARECAAYFAk4ITxYACgkQmnpgrYe6r60uPgCglGLFWWXEg+1fPxBB/MOM5eMZ
>> 3SsAnjkyZ82XAfEWIM0EOzuruWK2FQYX
>> =eLSM
>> -----END PGP SIGNATURE-----
>>
>
>
>
> --
> Dr Matthew Pocock
> Visitor, School of Computing Science, Newcastle University
> mailto: turingatemyhamster@gmail.com
> gchat: turingatemyhamster@gmail.com
> msn: matthew_pocock@yahoo.co.uk
> irc.freenode.net: drdozer
> (0191) 2566550
>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

This is very true. Learning category theory and understanding algebra
are definitely good things, but those sorts of reponses are very
off-putting to newcomers, and aren't very helpful in the short- or
medium-term.

On 06/27/2011 08:25 AM, Matthew Pocock wrote:
> I don't personally find responses along the lines of, "learn category
> theory" and, "you should understand algebra" either leads anyone towards
> enlightenment or welcomes them into the scala community.
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAk4IoCsACgkQ0GFaTS4nYxtzIACdEYgRj2mh+3t9p1ouDp4sZqGQ
U/sAoIDoTlPIIo8SYFz6CiQ2lT7J6MeN
=QOWl
-----END PGP SIGNATURE-----

I'm glad I'm not alone.  
Like Tony I enjoy learning new things - that's why I'm trying Scala.  
Thanks all for the support as well as the ideas.
Best regards
Ray
On 27 June 2011 15:22, Clint Gilbert <clint_gilbert@hms.harvard.edu> wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

This is very true.  Learning category theory and understanding algebra
are definitely good things, but those sorts of reponses are very
off-putting to newcomers, and aren't very helpful in the short- or
medium-term.

On 06/27/2011 08:25 AM, Matthew Pocock wrote:
> I don't personally find responses along the lines of, "learn category
> theory" and, "you should understand algebra" either leads anyone towards
> enlightenment or welcomes them into the scala community.
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAk4IoCsACgkQ0GFaTS4nYxtzIACdEYgRj2mh+3t9p1ouDp4sZqGQ
U/sAoIDoTlPIIo8SYFz6CiQ2lT7J6MeN
=QOWl
-----END PGP SIGNATURE-----

On Monday 27 June 2011, Clint Gilbert wrote:
> This is very true. Learning category theory and understanding
> algebra are definitely good things, but those sorts of reponses are
> very off-putting to newcomers, and aren't very helpful in the short-
> or medium-term.
>
> On 06/27/2011 08:25 AM, Matthew Pocock wrote:
> > I don't personally find responses along the lines of, "learn
> > category theory" and, "you should understand algebra" either leads
> > anyone towards enlightenment or welcomes them into the scala
> > community.

These things are _fundamental_ to this profession. If you won't learn
them, you don't deserve the attribute "professional."

And I feel that Scala is a tool for professionals, not dilettants. You
don't have to know all these things to start to use it, but you should
be willing to learn in order to understand why things are as they are
and to be able to create sound artifacts.

The reason computer systems are so hideously unreliable and error-prone
today is exactly 'cause so many of its paid, putatively professional
practitioners are ignorant of these principles. The sooner we put our
understanding on a sound formal groundwork, the sooner we can get
reliable information systems to the world.

And yeah, I myself have a long way to go. But I appreciate being pointed
in the right direction by those who are further down the road to a good
understanding. Ignorance is not shameful, but the refusal to fill it in
with understanding when you come to realize that ignorance _is_.

Randall Schulz

I see the sentiment that Scala needs an enum type. The reason it hasn't is really language complexity. Despite what's often written on the net, I tried very hard to keep Scala reasonably compact, i.e. not more complicated to describe than Java. This is no easy thing to do since Scala covers so much more ground than Java. The way I tried to achieve it is leave out some of the more complciated sapects of Java when they can be simulated or generalized. Examples are primitive operators, special annotation syntax, asserts, and enumerations. Each of these do not add that much to the language but they are fairly complicated to specify.

I'm not saying this was necessarily the right choice (indeed, right wrt to what criterion?),  just explaining what the issues are.

Cheers

 -- Martin


Since it covers so much more

On Mon, Jun 27, 2011 at 5:40 PM, Randall R Schulz <rschulz@sonic.net> wrote:

On Monday 27 June 2011, Clint Gilbert wrote:
> This is very true.  Learning category theory and understanding
> algebra are definitely good things, but those sorts of reponses are
> very off-putting to newcomers, and aren't very helpful in the short-
> or medium-term.
>
> On 06/27/2011 08:25 AM, Matthew Pocock wrote:
> > I don't personally find responses along the lines of, "learn
> > category theory" and, "you should understand algebra" either leads
> > anyone towards enlightenment or welcomes them into the scala
> > community.

These things are _fundamental_ to this profession. If you won't learn
them, you don't deserve the attribute "professional."

And I feel that Scala is a tool for professionals, not dilettants. You
don't have to know all these things to start to use it, but you should
be willing to learn in order to understand why things are as they are
and to be able to create sound artifacts.

The reason computer systems are so hideously unreliable and error-prone
today is exactly 'cause so many of its paid, putatively professional
practitioners are ignorant of these principles. The sooner we put our
understanding on a sound formal groundwork, the sooner we can get
reliable information systems to the world.

And yeah, I myself have a long way to go. But I appreciate being pointed
in the right direction by those who are further down the road to a good
understanding. Ignorance is not shameful, but the refusal to fill it in
with understanding when you come to realize that ignorance _is_.


Randall Schulz

--
----------------------------------------------
Martin Odersky
Prof., EPFL and CEO, Typesafe
PSED, 1015 Lausanne, Switzerland
Tel. EPFL: +41 21 693 6863
Tel. Typesafe: +41 21 691 4967

I think perhaps the Enumeration type in Scala could benefit from a redesign and some assurances of certain compiler optimisations.   I think a good re-design would solve a lot of the complaints people have about it.
- Josh

On Mon, Jun 27, 2011 at 12:19 PM, martin odersky <martin.odersky@epfl.ch> wrote:

I see the sentiment that Scala needs an enum type. The reason it hasn't is really language complexity. Despite what's often written on the net, I tried very hard to keep Scala reasonably compact, i.e. not more complicated to describe than Java. This is no easy thing to do since Scala covers so much more ground than Java. The way I tried to achieve it is leave out some of the more complciated sapects of Java when they can be simulated or generalized. Examples are primitive operators, special annotation syntax, asserts, and enumerations. Each of these do not add that much to the language but they are fairly complicated to specify.

I'm not saying this was necessarily the right choice (indeed, right wrt to what criterion?),  just explaining what the issues are.

Cheers

 -- Martin


Since it covers so much more

On Mon, Jun 27, 2011 at 5:40 PM, Randall R Schulz <rschulz@sonic.net> wrote:

On Monday 27 June 2011, Clint Gilbert wrote:
> This is very true.  Learning category theory and understanding
> algebra are definitely good things, but those sorts of reponses are
> very off-putting to newcomers, and aren't very helpful in the short-
> or medium-term.
>
> On 06/27/2011 08:25 AM, Matthew Pocock wrote:
> > I don't personally find responses along the lines of, "learn
> > category theory" and, "you should understand algebra" either leads
> > anyone towards enlightenment or welcomes them into the scala
> > community.

These things are _fundamental_ to this profession. If you won't learn
them, you don't deserve the attribute "professional."

And I feel that Scala is a tool for professionals, not dilettants. You
don't have to know all these things to start to use it, but you should
be willing to learn in order to understand why things are as they are
and to be able to create sound artifacts.

The reason computer systems are so hideously unreliable and error-prone
today is exactly 'cause so many of its paid, putatively professional
practitioners are ignorant of these principles. The sooner we put our
understanding on a sound formal groundwork, the sooner we can get
reliable information systems to the world.

And yeah, I myself have a long way to go. But I appreciate being pointed
in the right direction by those who are further down the road to a good
understanding. Ignorance is not shameful, but the refusal to fill it in
with understanding when you come to realize that ignorance _is_.


Randall Schulz

--
----------------------------------------------
Martin Odersky
Prof., EPFL and CEO, Typesafe
PSED, 1015 Lausanne, Switzerland
Tel. EPFL: +41 21 693 6863
Tel. Typesafe: +41 21 691 4967

+1 Matthew.
Number one rule of software development is Listen To Your Users.
If there are indeed better ways to do enums in pure as-is Scala, then why don't one of the brilliant functional coders always complaining here about Java refugee noobs write a simple how-to document explaining what to do in Scala in place of using a Java enum?
Then when this subject comes up again in the next few weeks, you can simply provide a URL to the document in stead of alienating a few more Scala users with more obnoxious condescending commentary.

On Mon, Jun 27, 2011 at 8:25 AM, Matthew Pocock <turingatemyhamster@gmail.com> wrote:

We see this issue every few weeks by the way.

Yes, which tells us one of: we don't have the right documentation; there is a genuine issue that needs addressing; the 'wrong' people are trying to use scala. As scala is a general purpose programming that has every intention of being main-stream, I think that rules the 3rd option out. I don't personally find responses along the lines of, "learn category theory" and, "you should understand algebra" either leads anyone towards enlightenment or welcomes them into the scala community.
Matthew

- --
Tony Morris
http://tmorris.net/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4ITxYACgkQmnpgrYe6r60uPgCglGLFWWXEg+1fPxBB/MOM5eMZ
3SsAnjkyZ82XAfEWIM0EOzuruWK2FQYX
=eLSM
-----END PGP SIGNATURE-----

--
Dr Matthew PocockVisitor, School of Computing Science, Newcastle Universitymailto: turingatemyhamster@gmail.com gchat: turingatemyhamster@gmail.commsn: matthew_pocock@yahoo.co.uk irc.freenode.net: drdozer(0191) 2566550

--
There are more things in heaven and earth, Horatio,
Than are dreamt of in your philosophy.

On Mon, Jun 27, 2011 at 5:40 PM, Randall R Schulz <rschulz@sonic.net> wrote:

These things are _fundamental_ to this profession. If you won't learn
them, you don't deserve the attribute "professional."

Tell that to Linus Thorvalds. Or Alan Kay. Or John McCarty. Or Donald Knuth. Or Martin Fowler. Or Joshua Bloch. Or Rich Hickey. Or ...
If the list looks somewhat random it is because it is. There are so ridiculously many great developers and computer scientists that don't really care about category theory. The vast majority don't. That's not to say it isn't useful, but claiming that you don't deserve the attribute "professional" if you don't learn "these things" is simply absurd. Anyone who claims that has a lot to prove.
Also, somehow it seems that people like Simon Peyton Jones, Phil Wadler, John Hughes etc manage to know a thing or two about these things without being jerks about it, so clearly it is possible. (And some people on this list, like Greg Meredith, Jason Zaugg and others, show that this is even possible within the Scala community).
Disclaimer:Obviously I can't speak for any of the names dropped above. My apologies if I'm mistaken about any of them. Also I don't generally find appeal to authority to be a convincing argument. But let me reiterate that I'm not claiming these things are not useful, I'm only objecting to the quoted assertion and to the manners of some people on this mailing list. 
Cheers,Daniel

Randall,

We're all willing to learn... it's why we are on these groups and
learning new languages.

I can (almost literally) feel your passion - and that's good. Please
however bear in mind that tone is important when one is trying to
encourage others.

As to enums, you never know, other FP languages might also have
support for Enums. I had a quick check and they are part of Haskell,
which I understand is a first class FP language. "Class Enum defines
operations on sequentially ordered types."
(http://www.haskell.org/ghc/docs/6.12.2/html/libraries/base-4.2.0.1/Prelu...).
I don't want to get into a war of Scala vs Haskell. I'm just saying
that this is not a purely Java language aspect.

Best regards

Ray

On 27 June 2011 15:40, Randall R Schulz wrote:
> On Monday 27 June 2011, Clint Gilbert wrote:
>> This is very true.  Learning category theory and understanding
>> algebra are definitely good things, but those sorts of reponses are
>> very off-putting to newcomers, and aren't very helpful in the short-
>> or medium-term.
>>
>> On 06/27/2011 08:25 AM, Matthew Pocock wrote:
>> > I don't personally find responses along the lines of, "learn
>> > category theory" and, "you should understand algebra" either leads
>> > anyone towards enlightenment or welcomes them into the scala
>> > community.
>
> These things are _fundamental_ to this profession. If you won't learn
> them, you don't deserve the attribute "professional."
>
> And I feel that Scala is a tool for professionals, not dilettants. You
> don't have to know all these things to start to use it, but you should
> be willing to learn in order to understand why things are as they are
> and to be able to create sound artifacts.
>
> The reason computer systems are so hideously unreliable and error-prone
> today is exactly 'cause so many of its paid, putatively professional
> practitioners are ignorant of these principles. The sooner we put our
> understanding on a sound formal groundwork, the sooner we can get
> reliable information systems to the world.
>
> And yeah, I myself have a long way to go. But I appreciate being pointed
> in the right direction by those who are further down the road to a good
> understanding. Ignorance is not shameful, but the refusal to fill it in
> with understanding when you come to realize that ignorance _is_.
>
>
> Randall Schulz
>

Resent to whole list:

I'm pretty sure that Haskell's Enum isn't what you think it is.

I realise that a there's a few of us coming across as jerks on this
thread, but it's difficult to help more than already has been offered.
The SO question has what I personally would consider to be the best
scala-only solution (case objects) and then the thread has had the
additional suggestion that if you *really* want java enums, to use
those. Your rejection of the case objects as being "hacky"doesn't
really make much sense to me, but I guess that's a personal aesthetics
thing.

It's not obvious to me how the suggestion I mailed to you (case
objects in a list tupled with the sizes) doesn't solve your problem,
unless your complaint is purely that it takes more lines than java. If
that's the case, I totally agree - it does indeed take more lines.

On Mon, Jun 27, 2011 at 6:37 PM, mond ray wrote:
> Randall,
>
> We're all willing to learn... it's why we are on these groups and
> learning new languages.
>
> I can (almost literally) feel your passion - and that's good.  Please
> however bear in mind that tone is important when one is trying to
> encourage others.
>
> As to enums, you never know, other FP languages might also have
> support for Enums.  I had a quick check and they are part of Haskell,
> which I understand is a first class FP language.  "Class Enum defines
> operations on sequentially ordered types."
> (http://www.haskell.org/ghc/docs/6.12.2/html/libraries/base-4.2.0.1/Prelu...).
>  I don't want to get into a war of Scala vs Haskell.  I'm just saying
> that this is not a purely Java language aspect.
>
> Best regards
>
> Ray
>
> On 27 June 2011 15:40, Randall R Schulz wrote:
>> On Monday 27 June 2011, Clint Gilbert wrote:
>>> This is very true.  Learning category theory and understanding
>>> algebra are definitely good things, but those sorts of reponses are
>>> very off-putting to newcomers, and aren't very helpful in the short-
>>> or medium-term.
>>>
>>> On 06/27/2011 08:25 AM, Matthew Pocock wrote:
>>> > I don't personally find responses along the lines of, "learn
>>> > category theory" and, "you should understand algebra" either leads
>>> > anyone towards enlightenment or welcomes them into the scala
>>> > community.
>>
>> These things are _fundamental_ to this profession. If you won't learn
>> them, you don't deserve the attribute "professional."
>>
>> And I feel that Scala is a tool for professionals, not dilettants. You
>> don't have to know all these things to start to use it, but you should
>> be willing to learn in order to understand why things are as they are
>> and to be able to create sound artifacts.
>>
>> The reason computer systems are so hideously unreliable and error-prone
>> today is exactly 'cause so many of its paid, putatively professional
>> practitioners are ignorant of these principles. The sooner we put our
>> understanding on a sound formal groundwork, the sooner we can get
>> reliable information systems to the world.
>>
>> And yeah, I myself have a long way to go. But I appreciate being pointed
>> in the right direction by those who are further down the road to a good
>> understanding. Ignorance is not shameful, but the refusal to fill it in
>> with understanding when you come to realize that ignorance _is_.
>>
>>
>> Randall Schulz
>>
>

Yes, it's OK.  Thanks.  We're all done bar the shouting.

On 27 June 2011 18:24, Alec Zorab wrote:
> Resent to whole list:
>
> I'm pretty sure that Haskell's Enum isn't what you think it is.
>
> I realise that a there's a few of us coming across as jerks on this
> thread, but it's difficult to help more than already has been offered.
> The SO question has what I personally would consider to be the best
> scala-only solution (case objects) and then the thread has had the
> additional suggestion that if you *really* want java enums, to use
> those. Your rejection of the case objects as being "hacky"doesn't
> really make much sense to me, but I guess that's a personal aesthetics
> thing.
>
> It's not obvious to me how the suggestion I mailed to you (case
> objects in a list tupled with the sizes) doesn't solve your problem,
> unless your complaint is purely that it takes more lines than java. If
> that's the case, I totally agree - it does indeed take more lines.
>
> On Mon, Jun 27, 2011 at 6:37 PM, mond ray wrote:
>> Randall,
>>
>> We're all willing to learn... it's why we are on these groups and
>> learning new languages.
>>
>> I can (almost literally) feel your passion - and that's good.  Please
>> however bear in mind that tone is important when one is trying to
>> encourage others.
>>
>> As to enums, you never know, other FP languages might also have
>> support for Enums.  I had a quick check and they are part of Haskell,
>> which I understand is a first class FP language.  "Class Enum defines
>> operations on sequentially ordered types."
>> (http://www.haskell.org/ghc/docs/6.12.2/html/libraries/base-4.2.0.1/Prelu...).
>>  I don't want to get into a war of Scala vs Haskell.  I'm just saying
>> that this is not a purely Java language aspect.
>>
>> Best regards
>>
>> Ray
>>
>> On 27 June 2011 15:40, Randall R Schulz wrote:
>>> On Monday 27 June 2011, Clint Gilbert wrote:
>>>> This is very true.  Learning category theory and understanding
>>>> algebra are definitely good things, but those sorts of reponses are
>>>> very off-putting to newcomers, and aren't very helpful in the short-
>>>> or medium-term.
>>>>
>>>> On 06/27/2011 08:25 AM, Matthew Pocock wrote:
>>>> > I don't personally find responses along the lines of, "learn
>>>> > category theory" and, "you should understand algebra" either leads
>>>> > anyone towards enlightenment or welcomes them into the scala
>>>> > community.
>>>
>>> These things are _fundamental_ to this profession. If you won't learn
>>> them, you don't deserve the attribute "professional."
>>>
>>> And I feel that Scala is a tool for professionals, not dilettants. You
>>> don't have to know all these things to start to use it, but you should
>>> be willing to learn in order to understand why things are as they are
>>> and to be able to create sound artifacts.
>>>
>>> The reason computer systems are so hideously unreliable and error-prone
>>> today is exactly 'cause so many of its paid, putatively professional
>>> practitioners are ignorant of these principles. The sooner we put our
>>> understanding on a sound formal groundwork, the sooner we can get
>>> reliable information systems to the world.
>>>
>>> And yeah, I myself have a long way to go. But I appreciate being pointed
>>> in the right direction by those who are further down the road to a good
>>> understanding. Ignorance is not shameful, but the refusal to fill it in
>>> with understanding when you come to realize that ignorance _is_.
>>>
>>>
>>> Randall Schulz
>>>
>>
>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 27/06/11 22:25, Matthew Pocock wrote:
>>
>>
>> We see this issue every few weeks by the way.
>>
>>
> the 'wrong' people are trying to use scala.

You missed off another alternative; many people are using (reasoning
about) scala (algebraic data types) wrong.

> I don't personally find responses along the lines of, "learn
> category theory" and, "you should understand algebra" either leads
> anyone towards enlightenment or welcomes them into the scala
> community.
>
> Matthew

Nobody ever said this. It just happens to be useful advice, despite
apparently irrational objections.


- --
Tony Morris
http://tmorris.net/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4I7toACgkQmnpgrYe6r60sPACfQVf7NRYxb5of9SlSNSYpVTm4
9FQAn17i1BWU2zOymRro0OAOHqlIw9UU
=PWwE
-----END PGP SIGNATURE-----

On Mon, Jun 27, 2011 at 4:58 PM, Tony Morris <tonymorris@gmail.com> wrote:

You missed off another alternative; many people are using (reasoning
about) scala (algebraic data types) wrong.

Absolutism does not befit an athiest.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 28/06/11 03:37, mond ray wrote:
> Randall,
>
> We're all willing to learn... it's why we are on these groups and
> learning new languages.
>
> I can (almost literally) feel your passion - and that's good.
> Please however bear in mind that tone is important when one is
> trying to encourage others.
>
> As to enums, you never know, other FP languages might also have
> support for Enums. I had a quick check and they are part of
> Haskell, which I understand is a first class FP language. "Class
> Enum defines operations on sequentially ordered types."
> (http://www.haskell.org/ghc/docs/6.12.2/html/libraries/base-4.2.0.1/Prelu...).
>
>
I don't want to get into a war of Scala vs Haskell. I'm just saying
> that this is not a purely Java language aspect.

This Haskell construct is very different to what is being demanded
here on this list. In particular, it is far far more useful, so if you
are going to request any language feature it is the more general
notion of "deriving" that haskell has.

On Mon, Jun 27, 2011 at 11:40 AM, Randall R Schulz <rschulz@sonic.net> wrote:

And I feel that Scala is a tool for professionals, not dilettants. You
don't have to know all these things to start to use it, but you should
be willing to learn in order to understand why things are as they are
and to be able to create sound artifacts.

And if, due to whatever circumstances that aren't really your business, someone cannot, does not, or does not want to, learn category theory, or relate to Scala as a mathematical body, then *you* *feel* that Scala is not for him??

The reason computer systems are so hideously unreliable and error-prone today is exactly 'cause so many of its paid, putatively professional
practitioners are ignorant of these principles. The sooner we put our
understanding on a sound formal groundwork, the sooner we can get
reliable information systems to the world.

So Scala enums present a barrier to creating a deterministic world! Poor athiests... 

And yeah, I myself have a long way to go. But I appreciate being pointed
in the right direction by those who are further down the road to a good
understanding. Ignorance is not shameful, but the refusal to fill it in
with understanding when you come to realize that ignorance _is_.

Not as shameful as disrespectful behavior.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 28/06/11 07:03, Naftoli Gugenheim wrote:
> On Mon, Jun 27, 2011 at 4:58 PM, Tony Morris
> wrote:
>
>> You missed off another alternative; many people are using
>> (reasoning about) scala (algebraic data types) wrong.
>>
>
> Absolutism does not befit an athiest.
>
WTF? It's atheist, not athiest. HTH.

On Mon, Jun 27, 2011 at 2:19 PM, Tony Morris <tonymorris@gmail.com> wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 28/06/11 07:03, Naftoli Gugenheim wrote:
> On Mon, Jun 27, 2011 at 4:58 PM, Tony Morris <tonymorris@gmail.com>
> wrote:
>
>> You missed off another alternative; many people are using
>> (reasoning about) scala (algebraic data types) wrong.
>>
>
> Absolutism does not befit an athiest.
>
WTF? It's atheist, not athiest. HTH.

WTF? That's the Obama campaign slogan, "Winning The Future." Are you trying to start a rumor that he's an atheist?

--
http://RussP.us

Another clarification for new users: I never thought that much of category theory and I am sure that one can become an expert Scala programmer without using it (or else I am not an expert programmer). If you like that sort of thing, you can apply it in Scala. To each their own.

But I very much hope that category theory will NOT become a prerequisite for intelligent discussion on this group. Frankly, I have seen too many community die from falling in this hole.

Best,

 -- Martin

Your feedback? This is what I do now instead of Java enums. It might not be the best approach, but it's what I came up with.
http://scabl.blogspot.com/2011/06/scala-enums.html

I based the Enum class I use on the Sgine's Enum class,
http://code.google.com/p/sgine/

It lets one do stuff like:

sealed abstract class Status extends Status.Value
object Status extends Enum[Status] {
case object Off extends Status
case object On extends Status

Status(Off, On)
}

sealed abstract class Planet(name: String,
val mass: Double,
val radius: Double)
extends Planet.Value(name) {
def surfaceGravity: Double = Planet.G * mass / (radius * radius)
def surfaceWeight(otherMass: Double): Double = otherMass * surfaceGravity
}
object Planet extends Enum[Planet] {
// universal gravitational constant(m3 kg-1 s-2)
val G: Double = 6.67300E-11

object Mercury extends Planet("Mercury", 3.303e+23, 2.4397e6)
object Venus extends Planet("Venus", 4.869e+24, 6.0518e6)
object Earth extends Planet("Earth", 5.976e+24, 6.37814e6)
object Mars extends Planet("Mars", 6.421e+23, 3.3972e6)
object Jupiter extends Planet("Jupitier", 1.9e+27, 7.1492e7)
object Saturn extends Planet("Saturn", 5.688e+26, 6.0268e7)
object Uranus extends Planet("Uranus", 8.686e+25, 2.5559e7)
object Neptune extends Planet("Neptune", 1.024e+26, 2.4746e7)

Planet(Mercury, Venus, Earth, Mars, Jupiter, Saturn, Uranus, Neptune)
}

Yea, you have to create a sealed class and object and you
have to register the enum members, but it gives me what I want.

Also, in my modified version I do not get the "MODULE$" field
of the enum class (but, as a result, mine is not quite as a clean as
the Sgine version).

Richard

On 06/27/2011 04:06 PM, john sullivan wrote:
> Your feedback? This is what I do now instead of Java enums. It might not
> be the best approach, but it's what I came up with.
>
> http://scabl.blogspot.com/2011/06/scala-enums.html

One of the problems with this is that Off is of type Off, not Status.

x.foldRight(Off) ... uh oh!

This works, but is quite ceremonious:

sealed trait Status {
def fold[X](off: => X, on: => X): X
}

object Status {
def off: Status = new Status {
def fold[X](off: => X, on: => X) = off
}
def on: Status = new Status {
def fold[X](off: => X, on: => X) = on
}
}

Still, I'd kil for a mechanism like Haskell's deriving. I have
something-like-it-yeah-not-really in scalaz.

PS: please do not support enums in the language, please!

On 28/06/11 09:41, richard emberson wrote:
> I based the Enum class I use on the Sgine's Enum class,
> http://code.google.com/p/sgine/
>
> It lets one do stuff like:
>
> sealed abstract class Status extends Status.Value
> object Status extends Enum[Status] {
> case object Off extends Status
> case object On extends Status
>
> Status(Off, On)
> }
>
> sealed abstract class Planet(name: String,
> val mass: Double,
> val radius: Double)
> extends Planet.Value(name) {
> def surfaceGravity: Double = Planet.G * mass / (radius * radius)
> def surfaceWeight(otherMass: Double): Double = otherMass *
> surfaceGravity
> }
> object Planet extends Enum[Planet] {
> // universal gravitational constant(m3 kg-1 s-2)
> val G: Double = 6.67300E-11
>
> object Mercury extends Planet("Mercury", 3.303e+23, 2.4397e6)
> object Venus extends Planet("Venus", 4.869e+24, 6.0518e6)
> object Earth extends Planet("Earth", 5.976e+24, 6.37814e6)
> object Mars extends Planet("Mars", 6.421e+23, 3.3972e6)
> object Jupiter extends Planet("Jupitier", 1.9e+27, 7.1492e7)
> object Saturn extends Planet("Saturn", 5.688e+26, 6.0268e7)
> object Uranus extends Planet("Uranus", 8.686e+25, 2.5559e7)
> object Neptune extends Planet("Neptune", 1.024e+26, 2.4746e7)
>
> Planet(Mercury, Venus, Earth, Mars, Jupiter, Saturn, Uranus, Neptune)
> }
>
> Yea, you have to create a sealed class and object and you
> have to register the enum members, but it gives me what I want.
>
> Also, in my modified version I do not get the "MODULE$" field
> of the enum class (but, as a result, mine is not quite as a clean as
> the Sgine version).
>
> Richard
>
>
> On 06/27/2011 04:06 PM, john sullivan wrote:
>> Your feedback? This is what I do now instead of Java enums. It might not
>> be the best approach, but it's what I came up with.
>>
>> http://scabl.blogspot.com/2011/06/scala-enums.html
>

I think this thead is about due for a barrage of cuddly kitten pictures.   awwwwhhh.... so cute.

On Jun 27, 2011 5:48 PM, "Russ Paielli" <russ.paielli@gmail.com> wrote:
> On Mon, Jun 27, 2011 at 2:19 PM, Tony Morris <tonymorris@gmail.com> wrote:
>
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 28/06/11 07:03, Naftoli Gugenheim wrote:
>> > On Mon, Jun 27, 2011 at 4:58 PM, Tony Morris <tonymorris@gmail.com>
>> > wrote:
>> >
>> >> You missed off another alternative; many people are using
>> >> (reasoning about) scala (algebraic data types) wrong.
>> >>
>> >
>> > Absolutism does not befit an athiest.
>> >
>> WTF? It's atheist, not athiest. HTH.
>>
>>
> WTF? That's the Obama campaign slogan, "Winning The Future." Are you trying
> to start a rumor that he's an atheist?
>
> --
> http://RussP.us

Haskell's Enum is a type class which describes a partial mapping between some integers to values of a type. Scala could certainly have a similar "type class".  What makes Haskell interesting here is that an instance Haskell's Enum type class can be derived automatically from an algebraic data type where none of the constructors take arguments.  It's an interesting middle ground between Java where it's a core language feature and Scala where it's not a language feature at all.  In Haskell Enum isn't a language feature but "deriving Enum" is.

On Mon, Jun 27, 2011 at 10:37 AM, mond ray <mondraymond@gmail.com> wrote:

Randall,

We're all willing to learn... it's why we are on these groups and
learning new languages.

I can (almost literally) feel your passion - and that's good.  Please
however bear in mind that tone is important when one is trying to
encourage others.

As to enums, you never know, other FP languages might also have
support for Enums.  I had a quick check and they are part of Haskell,
which I understand is a first class FP language.  "Class Enum defines
operations on sequentially ordered types."
(http://www.haskell.org/ghc/docs/6.12.2/html/libraries/base-4.2.0.1/Prelude.html#t%3AEnum).
 I don't want to get into a war of Scala vs Haskell.  I'm just saying
that this is not a purely Java language aspect.

Best regards

Ray

On 27 June 2011 15:40, Randall R Schulz <rschulz@sonic.net> wrote:
> On Monday 27 June 2011, Clint Gilbert wrote:
>> This is very true.  Learning category theory and understanding
>> algebra are definitely good things, but those sorts of reponses are
>> very off-putting to newcomers, and aren't very helpful in the short-
>> or medium-term.
>>
>> On 06/27/2011 08:25 AM, Matthew Pocock wrote:
>> > I don't personally find responses along the lines of, "learn
>> > category theory" and, "you should understand algebra" either leads
>> > anyone towards enlightenment or welcomes them into the scala
>> > community.
>
> These things are _fundamental_ to this profession. If you won't learn
> them, you don't deserve the attribute "professional."
>
> And I feel that Scala is a tool for professionals, not dilettants. You
> don't have to know all these things to start to use it, but you should
> be willing to learn in order to understand why things are as they are
> and to be able to create sound artifacts.
>
> The reason computer systems are so hideously unreliable and error-prone
> today is exactly 'cause so many of its paid, putatively professional
> practitioners are ignorant of these principles. The sooner we put our
> understanding on a sound formal groundwork, the sooner we can get
> reliable information systems to the world.
>
> And yeah, I myself have a long way to go. But I appreciate being pointed
> in the right direction by those who are further down the road to a good
> understanding. Ignorance is not shameful, but the refusal to fill it in
> with understanding when you come to realize that ignorance _is_.
>
>
> Randall Schulz
>

Here is the library part written in Java
http://functionaljava.googlecode.com/svn/artifacts/3.0/javadoc/fj/data/Enumerator.html

Again, the deriving language feature would be great imo.


On 28/06/11 13:07, James Iry wrote:

V0A [at] mail [dot] gmail [dot] com" type="cite">Haskell's Enum is a type class which describes a partial mapping between some integers to values of a type. Scala could certainly have a similar "type class".  What makes Haskell interesting here is that an instance Haskell's Enum type class can be derived automatically from an algebraic data type where none of the constructors take arguments.  It's an interesting middle ground between Java where it's a core language feature and Scala where it's not a language feature at all.  In Haskell Enum isn't a language feature but "deriving Enum" is.

On Mon, Jun 27, 2011 at 10:37 AM, mond ray <mondraymond [at] gmail [dot] com" target="_blank" rel="nofollow">mondraymond@gmail.com> wrote:

Randall,

We're all willing to learn... it's why we are on these groups and
learning new languages.

I can (almost literally) feel your passion - and that's good.  Please
however bear in mind that tone is important when one is trying to
encourage others.

As to enums, you never know, other FP languages might also have
support for Enums.  I had a quick check and they are part of Haskell,
which I understand is a first class FP language.  "Class Enum defines
operations on sequentially ordered types."
(http://www.haskell.org/ghc/docs/6.12.2/html/libraries/base-4.2.0.1/Prelude.html#t%3AEnum).
 I don't want to get into a war of Scala vs Haskell.  I'm just saying
that this is not a purely Java language aspect.

Best regards

Ray

On 27 June 2011 15:40, Randall R Schulz <rschulz [at] sonic [dot] net" target="_blank" rel="nofollow">rschulz@sonic.net> wrote:
> On Monday 27 June 2011, Clint Gilbert wrote:
>> This is very true.  Learning category theory and understanding
>> algebra are definitely good things, but those sorts of reponses are
>> very off-putting to newcomers, and aren't very helpful in the short-
>> or medium-term.
>>
>> On 06/27/2011 08:25 AM, Matthew Pocock wrote:
>> > I don't personally find responses along the lines of, "learn
>> > category theory" and, "you should understand algebra" either leads
>> > anyone towards enlightenment or welcomes them into the scala
>> > community.
>
> These things are _fundamental_ to this profession. If you won't learn
> them, you don't deserve the attribute "professional."
>
> And I feel that Scala is a tool for professionals, not dilettants. You
> don't have to know all these things to start to use it, but you should
> be willing to learn in order to understand why things are as they are
> and to be able to create sound artifacts.
>
> The reason computer systems are so hideously unreliable and error-prone
> today is exactly 'cause so many of its paid, putatively professional
> practitioners are ignorant of these principles. The sooner we put our
> understanding on a sound formal groundwork, the sooner we can get
> reliable information systems to the world.
>
> And yeah, I myself have a long way to go. But I appreciate being pointed
> in the right direction by those who are further down the road to a good
> understanding. Ignorance is not shameful, but the refusal to fill it in
> with understanding when you come to realize that ignorance _is_.
>
>
> Randall Schulz
>

-- 
Tony Morris
http://tmorris.net/

On Monday 27 June 2011, john sullivan wrote:
> +1 Matthew.
>
> Number one rule of software development is Listen To Your Users.
>
> ...

That's not really saying much. All relationships between providers of
something and users or consumers of that thing require a dialog. But
listening to your users doesn't mean saying "yes" to everything they
ask for. That is a nearly guaranteed recipe for chaos and failure.

Martin has made it clear that cost in terms of language complexity for
something as limited in its payback as Java-style enums is not
acceptable. So those who cannot do without them can wail and gnash
their teeth all they want, but they're not going to get what they want
this time. So why persist?

Randall Schulz

Thanks. It's good to know that the leaders of the community are
welcoming and patient.

On 27 June 2011 23:29, martin odersky wrote:
> Another clarification for new users: I never thought that much of category
> theory and I am sure that one can become an expert Scala programmer without
> using it (or else I am not an expert programmer). If you like that sort of
> thing, you can apply it in Scala. To each their own.
>
> But I very much hope that category theory will NOT become a prerequisite for
> intelligent discussion on this group. Frankly, I have seen too many
> community die from falling in this hole.
>
> Best,
>
>  -- Martin
>
>

I like this and will use it as a starting point.  You have captured the use case and a reasonable solution very well.  
Excellent work - thanks.
Ray

> Number one rule of software development is Listen To Your Users.

That's not really saying much.

It's saying a lot. Most people are terrible listeners. Somebody talks at them and they only half listen because they already think they know what the person wants to say. They don't like what the person has to say and so they twist it into something else. Sometimes people are just looking for an argument, and they take everything that is said to them as an affront.
Take for example. You seem to think that I want the Scala language to have an enum language feature, and that I am complaining because it does not have one. I am quite happy using hierarchies of case objects in place of enums, and I think that adding enums to the Scala language is not necessary and would make the language less elegant. But, it would have been much better for me if, the first time I tried to "make an enumeration type" in Scala, I had found a clear and simple example of how to do enums with Scala case objects, and had not found scala.Enumeration instead. I did find some hints and suggestions here and there that eventually led me to figure out a relatively decent pattern for replacing enums on my own, but I found out by trial and error, and I'm not convinced that the solution I have settled on couldn't be improved upon.
Of course listening does not mean just saying "yes" to whatever your users ask for. That's not really listening at all actually, is it? A very simple turing machine could do the same. Listening means trying to understand what the person actually wants or needs. When you have a pattern of conversations with your users that goes, while (true) { "I want this", "No you don't, that's stupid" }, you need to break out of the loop and see what you are missing. (I know that's not a fair characterization of this conversation, but it certainly can feel that way to someone posting to a list in hopes of getting some help with a programming problem they are having.)
Good listening includes making the translation from what the user thinks they want, or says they want, to what they actually need. As the software developer we are in a position to say, "you are asking for this particular feature, but the problem you are actually trying to solve is such-and-such. Let me suggest some other ways of achieving your goal than the specific feature you have requested."  

All relationships between providers of
something and users or consumers of that thing require a dialog. But
listening to your users doesn't mean saying "yes" to everything they
ask for. That is a nearly guaranteed recipe for chaos and failure.

Martin has made it clear that cost in terms of language complexity for
something as limited in its payback as Java-style enums is not
acceptable. So those who cannot do without them can wail and gnash
their teeth all they want, but they're not going to get what they want
this time. So why persist?


Randall Schulz

--
There are more things in heaven and earth, Horatio,
Than are dreamt of in your philosophy.

As Josh said a while ago, it's kitten time now.

I think we made progress.

Thanks for your help and support.

On 28 June 2011 14:42, john sullivan wrote:
>> > Number one rule of software development is Listen To Your Users.
>>
>> That's not really saying much.
>
> It's saying a lot. Most people are terrible listeners. Somebody talks at
> them and they only half listen because they already think they know what the
> person wants to say. They don't like what the person has to say and so they
> twist it into something else. Sometimes people are just looking for an
> argument, and they take everything that is said to them as an affront.
> Take for example. You seem to think that I want the Scala language to have
> an enum language feature, and that I am complaining because it does not have
> one. I am quite happy using hierarchies of case objects in place of enums,
> and I think that adding enums to the Scala language is not necessary and
> would make the language less elegant. But, it would have been much better
> for me if, the first time I tried to "make an enumeration type" in Scala, I
> had found a clear and simple example of how to do enums with Scala case
> objects, and had not found scala.Enumeration instead. I did find some hints
> and suggestions here and there that eventually led me to figure out a
> relatively decent pattern for replacing enums on my own, but I found out by
> trial and error, and I'm not convinced that the solution I have settled on
> couldn't be improved upon.
> Of course listening does not mean just saying "yes" to whatever your users
> ask for. That's not really listening at all actually, is it? A very simple
> turing machine could do the same. Listening means trying to understand what
> the person actually wants or needs. When you have a pattern of conversations
> with your users that goes, while (true) { "I want this", "No you don't,
> that's stupid" }, you need to break out of the loop and see what you are
> missing. (I know that's not a fair characterization of this conversation,
> but it certainly can feel that way to someone posting to a list in hopes of
> getting some help with a programming problem they are having.)
> Good listening includes making the translation from what the user thinks
> they want, or says they want, to what they actually need. As the software
> developer we are in a position to say, "you are asking for this particular
> feature, but the problem you are actually trying to solve is such-and-such.
> Let me suggest some other ways of achieving your goal than the specific
> feature you have requested."
>
>>
>> All relationships between providers of
>> something and users or consumers of that thing require a dialog. But
>> listening to your users doesn't mean saying "yes" to everything they
>> ask for. That is a nearly guaranteed recipe for chaos and failure.
>>
>> Martin has made it clear that cost in terms of language complexity for
>> something as limited in its payback as Java-style enums is not
>> acceptable. So those who cannot do without them can wail and gnash
>> their teeth all they want, but they're not going to get what they want
>> this time. So why persist?
>>
>>
>> Randall Schulz
>
>
>
> --
> There are more things in heaven and earth, Horatio,
> Than are dreamt of in your philosophy.
>

> On 06/27/2011 08:25 AM, Matthew Pocock wrote:
> > I don't personally find responses along the lines of, "learn
> > category theory" and, "you should understand algebra" either leads
> > anyone towards enlightenment or welcomes them into the scala
> > community.

These things are _fundamental_ to this profession. If you won't learn
them, you don't deserve the attribute "professional."

Um, no, they are not. There are a great many true professionals out there writing fantastic, tight, reliable code, who don't have a clue what category theory or algebraic data types are. I worked for a company (Be Inc.) that was filled with them, and I read their code. Unit testing is _fundamental_ to this profession. Consistent APIs are _fundamental_ to this profession. Category theory--_not_ fundamental. Nice to have, and if someone points me to good tutorials on cat theory and alg data types I'll go through them--but hey, I'm unemployed.
There is a very funny/sad book called "Night Watch" by Terry Pratchett that talks about how, if political revolution isn't accepted by the people, then the obvious next step is that you need to change the people. I sense some amount of that feeling around Scala--"if people don't see the brilliance of Scala, then the people need to be changed." Well, people do see a lot of the brilliance of Scala, and that's great; but enums are something the keep coming up, which should make us think not, "how do we change people", but, "how do we do enums properly in Scala in a way that will be accepted by the audience we are aiming at.
Oh and I'm serious about the tutorials, so please feel free to provide links.
Ken

I really wish it were commonly held wisdom that unit testing is
fundamental, but my experience indicates that this is not the case!

On Tue, Jun 28, 2011 at 5:54 PM, Ken McDonald wrote:
>> > On 06/27/2011 08:25 AM, Matthew Pocock wrote:
>> > > I don't personally find responses along the lines of, "learn
>> > > category theory" and, "you should understand algebra" either leads
>> > > anyone towards enlightenment or welcomes them into the scala
>> > > community.
>>
>> These things are _fundamental_ to this profession. If you won't learn
>> them, you don't deserve the attribute "professional."
>
> Um, no, they are not. There are a great many true professionals out there
> writing fantastic, tight, reliable code, who don't have a clue what category
> theory or algebraic data types are. I worked for a company (Be Inc.) that
> was filled with them, and I read their code. Unit testing is _fundamental_
> to this profession. Consistent APIs are _fundamental_ to this profession.
> Category theory--_not_ fundamental. Nice to have, and if someone points me
> to good tutorials on cat theory and alg data types I'll go through them--but
> hey, I'm unemployed.
> There is a very funny/sad book called "Night Watch" by Terry Pratchett that
> talks about how, if political revolution isn't accepted by the people, then
> the obvious next step is that you need to change the people. I sense some
> amount of that feeling around Scala--"if people don't see the brilliance of
> Scala, then the people need to be changed." Well, people do see a lot of the
> brilliance of Scala, and that's great; but enums are something the keep
> coming up, which should make us think not, "how do we change people", but,
> "how do we do enums properly in Scala in a way that will be accepted by the
> audience we are aiming at.
> Oh and I'm serious about the tutorials, so please feel free to provide
> links.
> Ken