enums in dart

[Pete]

any plans to support enums in dart?

it would be nice to have extensible enums that support inheritance;
unlike those in java that don't support it

[Rémi Forax]

there is a question to answer before, why do you want enums to be classes ?

R�mi

[Ruudjah]

http://code.google.com/p/dart/issues/detail?id=88

[Pete Marshall]

Other than serializing to xml (where xml schema has enumeration), and annotations (java annotations need enums so I guess Darts will as well), is there a case where an enum is required because an abstract base with concretes wont work in Dart (or Java for that matter)? 

Pete

[Pete]

* use of enums provides type-checking and produces code that is more
robust and less prone to errors.

* a use case for why i need this:
think of a library that returns the result code for an operation as an
enum. now think of an another library that extends it and needs to
add more result codes.

* they don't have to be classes, but they should be extensible

[Don Olmstead]

How is the original library supposed to handle it when someone inevitably passes the extended enum into it? It has no knowledge of whatever additional values you've added to it, so what happens? How can it deal with this behavior?

Extending an enum sounds like trouble to me. The particular use case you mention sounds like something you'd solve by either creating your own enum, and then mapping the libraries' values to this enum, or creating a class wrapping info on the result code.

This proposal would add unneeded complexity to something that should be really simple.

[Rémi Forax]

On 07/14/2012 07:20 PM, Pete wrote:

Hi Pete,

> * use of enums provides type-checking and produces code that is more
> robust and less prone to errors.
>
> * a use case for why i need this:
> think of a library that returns the result code for an operation as an
> enum. now think of an another library that extends it and needs to
> add more result codes.
>
> * they don't have to be classes, but they should be extensible

The problem is that these requirements are antagonistic.
If you can extend an enum and add add new value, then all functions/methods
that take this enum has parameter will have a broken semantics
because unlike with a class that embodies the part of the semantics
enum values carry no behavior.

An enum is a closed type not an open one,
and the fact that Java allows abstract methods on an enum did not help.

R�mi

[goosy jo]

support!

without enum:

class Snake {

  static final int UP = -2, DOWN = 2, LEFT=-1, RIGHT=1;

  int direction;

}

int main(){

  new Snake().direction=8; // no wrong

}

within enum:

enum Direction { UP, DOWN, LEFT, RIGHT};

class Snake {

  Direction direction;

}

int main(){

  Snake s=new Snake()

  s.direction=RIGHT; // OK

  s.direction=8; //wrong

}

[Eric Leese]

Extensible enums flip inheritance on its head:

enum WeekDay { Monday, Tuesday, Wednesday, Thursday, Friday }
enum Day extends WeekDay { Saturday, Sunday }

Normally "extends" indicates a subclass, so any Day would also be a
WeekDay. But the opposite is true -- a WeekDay is a Day. So any enum
implements all the enums that extend it, but not the other way
around. This could be clarified by using a different keyword, like
maybe "includes". Then the type checker could make sure you passed
Days or WeekDays to functions expecting a Day, but did not pass Days
to a function expecting a weekday.

WeekDay.Tuesday is Day == true
Day.Wednesday is WeekDay == true
Day.Saturday is WeekDay == false

There is a workable, safe inheritance model here, but it's not one
programmers are used to. The language also gets tricky if you allow
inclusion of multiple enums in one, particularly if you want the
compiler to automatically ensure that values included from different
base enums do not overlap:

enum WeekDay { Monday, Tuesday, Wednesday, Thursday, Friday }
enum WeekendDay { Saturday, Sunday }
enum Day includes WeekDay, WeekendDay {}

Then again, if you don't alias enums to ints but instead have each
enum value be a reference to a different constant object, much like
null, false, and true, then there's really no reason that should be
any more difficult.

[Pete Marshall]

Hi,

  First of I agree that static final is bad - no need to go there.

  Your example isn't a case where an enum is required at all. Polymorphism will do the job. Where did direction come from and what do you intend to do with the direction?? 

Assume the direction comes from outside the system(key press, network, file).  You seem to want a snake with a directional quality, so have the boundary layer create an appropriate snake. Have the boundary make a LeftSnake or a RightSnake etc but it should be abstract.  Configuration will map key presses into snakes.  A Left snake knows what noise to make for left, what color to go when going left, how to move left.  Its what dependency injection is for.

Now when the snake moves, call snake.move(); Because you actually have a LeftSnake it will move left.  Call snake.makeNoise() - will cause the snake to make a left noise etc.

Please don't write :

switch snake.getDirection() ..

  case LEFT //do some left moving maths

  case RIGHT //do right moving maths

someone else will write

switch on snake.getDirection()

  case LEFT //draw a red snake

  case RIGHT // draw a green snake

 etc

and someone else will write

 case LEFT // make a bong noise

etc

This is the snakes job.

An alternative (because I'm not comfortable with mapping direction events to snakes) is to make a Direction object with a bearing property.  Then call snake.move(direction) where the move method will call back on 

direction to get the bearing. 

Pete

[David Kerr]

Hi

Whilst (as an OO enthusiast/bigot) I agree constantly using the enum to control behaviour (the switch statements) is bad and polymorphism is the better approach, a simple enum is 

1. so much more compact than the interface/base-class and concrete implementations
   
2. enums are nice and descriptive.
3. Java has them ;)

I think the Java advice is to only switch on them once, to create the concrete sub-class. I also think Java held off on enums for so long because the "correct" approach is polymorphism.

I'm just saying that, pragmatically, they have their place.

David K

[Dirk Detering]

Am 09.08.2012 15:34 schrieb "David Kerr" <iandav...@gmail.com>:
> Whilst (as an OO enthusiast/bigot) I agree constantly using the enum to control behaviour (the switch statements) is bad and polymorphism is the better approach,

Don't see that. It may be the more pure approach (in OO), but not necessarily the better *in all cases*.

>a simple enum is 
> so much more compact than the interface/base-class and concrete implementations
> enums are nice and descriptive.
> Java has them ;)

> I think the Java advice is to only switch on them once, to create the concrete sub-class. I also think Java held off on enums for so long because the "correct" approach is polymorphism.
>

Enums are types with a finite set of distinct named values. What's wrong with them?

Switching on enums shouldn't be more wrong than switching on int values or char values or whatever.

A behaviour is not always correct and not always doable on the original type.

> I'm just saying that, pragmatically, they have their place.

More than only 'pragmatically' I would say...

But extensibility seems wrong!

KR
Det

> --
> Consider asking HOWTO questions at Stack Overflow: http://stackoverflow.com/tags/dart
>  
>  

[Don Olmstead]

I'm in full agreement with Dirk here. Those with a background in Java see their setup where enums are classes as more extensible and OO. Those with a C/C++/C# background see it as just adding another layer of crap over what is fundamentally simple, that an enum is just a finite set of values. This finite set is used to increase the clarity of the code written.

I'm still in the keep it simple camp, and have my fingers crossed that whenever Dart finally adds enums that they'll be the C/C++/C# style instead of the Java style.

[Ladislav Thon]

I'm in full agreement with Dirk here. Those with a background in Java see their setup where enums are classes as more extensible and OO. Those with a C/C++/C# background see it as just adding another layer of crap over what is fundamentally simple, that an enum is just a finite set of values. This finite set is used to increase the clarity of the code written.

Totally agree with Dirk too. In some cases (polymorphism instead of enums being one of them), using pure OO aproach leads to the code for one algorithm being spread into a number of places. That is highly unreadable.

 

I'm still in the keep it simple camp, and have my fingers crossed that whenever Dart finally adds enums that they'll be the C/C++/C# style instead of the Java style.

Also, Java-style enums are patented :-)

LT

[Don Olmstead]

Worst patent ever ;)

--

[Florian Loitsch]

On Thu, Aug 9, 2012 at 7:29 PM, Don Olmstead <don.j.o...@gmail.com> wrote:

I'm in full agreement with Dirk here. Those with a background in Java see their setup where enums are classes as more extensible and OO. Those with a C/C++/C# background see it as just adding another layer of crap over what is fundamentally simple, that an enum is just a finite set of values. This finite set is used to increase the clarity of the code written.

I'm still in the keep it simple camp, and have my fingers crossed that whenever Dart finally adds enums that they'll be the C/C++/C# style instead of the Java style.

The C/C++/C# enums are generally a poor fit for dynamically typed languages. Basically they just give a different names to integers and use some static checking to provide some nice properties (like making sure that a switch is exhaustive).

In a dynamically typed language this is less useful, since the enum-type disappears at runtime. A completely untyped program would have almost no benefit from enums.

--
Give a man a fire and he's warm for the whole day,
but set fire to him and he's warm for the rest of his life. - Terry Pratchett

[Rémi Forax]

On 08/14/2012 02:15 PM, Florian Loitsch wrote:
> On Thu, Aug 9, 2012 at 7:29 PM, Don Olmstead <don.j.o...@gmail.com
> <mailto:don.j.o...@gmail.com>> wrote:
>
> I'm in full agreement with Dirk here. Those with a background in
> Java see their setup where enums are classes as more extensible
> and OO. Those with a C/C++/C# background see it as just adding
> another layer of crap over what is fundamentally simple, that an
> enum is just a finite set of values. This finite set is used to
> increase the clarity of the code written.
>
> I'm still in the keep it simple camp, and have my fingers crossed
> that whenever Dart finally adds enums that they'll be the C/C++/C#
> style instead of the Java style.
>
> The C/C++/C# enums are generally a poor fit for dynamically typed
> languages. Basically they just give a different names to integers and
> use some static checking to provide some nice properties (like making
> sure that a switch is exhaustive).
> In a dynamically typed language this is less useful, since the
> enum-type disappears at runtime. A completely untyped program would
> have almost no benefit from enums.

why do you think that enums should loose their type at runtime ?
enum can be implemented as value type, and boxed when necessary.

R�mi

[Kevin Moore]

From my perspective, runtime verification is not the big selling point for enums.

It's editor support.

C# does an amazing job of suggesting enum values when one does comparison against an enum or uses an enum value in a switch statement.

Getting warnings that I'm comparing or switching an int with a AlignmentEnum (or whatever) is also great for productivity.

If the runtime optimizes things down to ints (like C#) I really don't care.

On Tue, Aug 14, 2012 at 10:15 AM, Rémi Forax <fo...@univ-mlv.fr> wrote:

On 08/14/2012 02:15 PM, Florian Loitsch wrote:

On Thu, Aug 9, 2012 at 7:29 PM, Don Olmstead <don.j.o...@gmail.com <mailto:don.j.olmstead@gmail.com>> wrote:

    I'm in full agreement with Dirk here. Those with a background in
    Java see their setup where enums are classes as more extensible
    and OO. Those with a C/C++/C# background see it as just adding
    another layer of crap over what is fundamentally simple, that an
    enum is just a finite set of values. This finite set is used to
    increase the clarity of the code written.

    I'm still in the keep it simple camp, and have my fingers crossed
    that whenever Dart finally adds enums that they'll be the C/C++/C#
    style instead of the Java style.

The C/C++/C# enums are generally a poor fit for dynamically typed languages. Basically they just give a different names to integers and use some static checking to provide some nice properties (like making sure that a switch is exhaustive).
In a dynamically typed language this is less useful, since the enum-type disappears at runtime. A completely untyped program would have almost no benefit from enums.

why do you think that enums should loose their type at runtime ?
enum can be implemented as value type, and boxed when necessary.

Rémi

[Florian Loitsch]

On Tue, Aug 14, 2012 at 4:15 PM, Rémi Forax <fo...@univ-mlv.fr> wrote:

On 08/14/2012 02:15 PM, Florian Loitsch wrote:

On Thu, Aug 9, 2012 at 7:29 PM, Don Olmstead <don.j.o...@gmail.com <mailto:don.j.olmstead@gmail.com>> wrote:

    I'm in full agreement with Dirk here. Those with a background in
    Java see their setup where enums are classes as more extensible
    and OO. Those with a C/C++/C# background see it as just adding
    another layer of crap over what is fundamentally simple, that an
    enum is just a finite set of values. This finite set is used to
    increase the clarity of the code written.

    I'm still in the keep it simple camp, and have my fingers crossed
    that whenever Dart finally adds enums that they'll be the C/C++/C#
    style instead of the Java style.

The C/C++/C# enums are generally a poor fit for dynamically typed languages. Basically they just give a different names to integers and use some static checking to provide some nice properties (like making sure that a switch is exhaustive).
In a dynamically typed language this is less useful, since the enum-type disappears at runtime. A completely untyped program would have almost no benefit from enums.

why do you think that enums should loose their type at runtime ?
enum can be implemented as value type, and boxed when necessary.

C, C++ and C# enums are just aliases for integers. Therefore they don't have a different type during runtime. If enums have a different runtime semantics than integers then they don't fall into the C/C++/C# category anymore.

Rémi

--
Consider asking HOWTO questions at Stack Overflow: http://stackoverflow.com/tags/dart

[Don Olmstead]

We all know that enums are aliased to integers, properties under the hood are just methods, and Santa Claus isn't real. You guys made a language descending from C so enums are expected. Java started without enums, causing everyone to jump through the same hoops we currently have to in Dart to get enums, then they relented and added enums. C# saw what was happening with Java and had enums from the start.

Even in dynamic languages people still ask how to do enums, creating increasingly convoluted solutions

http://stackoverflow.com/questions/75759/enums-in-ruby 

http://stackoverflow.com/questions/36932/whats-the-best-way-to-implement-an-enum-in-python 

Lets just skip to Java 5.0 and figure out how to do enums in Dart.

[Seth Ladd]

Friendly reminder, if you care about enums, please star the bug and add any use cases you might have: http://code.google.com/p/dart/issues/detail?id=88

Thanks!

[Christopher Wright]

What prevents the compilers guys from making enums an immutable type consisting of an int, a constructor, some static fields, and a bunch of operators? It's an Object, so you can store it as such. It has some extra runtime overhead due to indirection, I grant, but that's relatively minor.

[W. Brian Gourlie]

I'm hesitant to star this bug because it's for implementing enums like java enums, which I'm definitely against.

[Don Olmstead]

I originally had a bug saying an enum like C/C++/C# but it was merged into that bug.

[mythz]

Likewise I've only starred it because I would like to see C/C# style enums: Simple & efficient.

[Cassio Tavares]

The good and old "simple". I agree.

[Rémi Forax]

On 08/14/2012 10:14 PM, mythz wrote:
> Likewise I've only starred it because I would like to see C/C# style
> enums: Simple & efficient.

BTW, it's worth to repeat that Dart int are not simple and efficient
C/C++ int but Python int.

R�mi

>
>
> On Tuesday, August 14, 2012 1:22:40 PM UTC-4, W. Brian Gourlie wrote:
>
> I'm hesitant to star this bug because it's for implementing enums
> like java enums, which I'm definitely against.
>
> On Tuesday, August 14, 2012 11:47:29 AM UTC-5, Seth Ladd wrote:
>
> Friendly reminder, if you care about enums, please star the
> bug and add any use cases you might have:
> http://code.google.com/p/dart/issues/detail?id=88
> <http://code.google.com/p/dart/issues/detail?id=88>
>
> Thanks!
>
>
> On Tue, Aug 14, 2012 at 8:29 AM, Don Olmstead
> <don.j.o...@gmail.com> wrote:
>
> We all know that enums are aliased to integers, properties
> under the hood are just methods, and Santa Claus isn't
> real. You guys made a language descending from C so enums
> are expected. Java started without enums, causing everyone
> to jump through the same hoops we currently have to in
> Dart to get enums, then they relented and added enums. C#
> saw what was happening with Java and had enums from the
> start.
>
> Even in dynamic languages people still ask how to do
> enums, creating increasingly convoluted solutions
>
> http://stackoverflow.com/questions/75759/enums-in-ruby

> <http://stackoverflow.com/questions/75759/enums-in-ruby>
> http://stackoverflow.com/questions/36932/whats-the-best-way-to-implement-an-enum-in-python

> <http://stackoverflow.com/questions/36932/whats-the-best-way-to-implement-an-enum-in-python>
>
>
> Lets just skip to Java 5.0 and figure out how to do enums
> in Dart.
>
>
> On Tue, Aug 14, 2012 at 7:20 AM, Florian Loitsch
> <floi...@google.com> wrote:
>

> On Tue, Aug 14, 2012 at 4:15 PM, R�mi Forax

> R�mi