[dart-misc] Enum Limitations

[Man Hoang]

As far as I can see, there are two big limitations of enum at the moment.

1. No easy way to know if an object is an enum (of and kind)

var isEnum = (value ! null) && reflectClass(value.runtimeType).isEnum;

// In C#, it's so easy
// var isEnum = value is Enum;


2. No built-in support for parsing an integer or a string into an enum
value. This is how I implement my own parsing method.

/// Converts [input], which is an integer or a string, into an enum
value of
/// type [enumType].
/// Returns `null` if fails.
parseEnum(input, Type enumType) {
try {
var values = reflectClass(enumType).getField(#values).reflectee;
if (input is int) {
return values[input];
}
for (var value in values) {
if (value.toString().split('.')[1] == input) {
return value;
}
}
} catch (e) {
}
return null;
}

So, will the Dart team resolve these limitations in the next version of the
language?

[Joel Trottier-Hébert]

+1

Post by Man Hoang
As far as I can see, there are two big limitations of enum at the moment.
1. No easy way to know if an object is an enum (of and kind)
var isEnum = (value ! null) && reflectClass(value.runtimeType).isEnum;
// In C#, it's so easy
// var isEnum = value is Enum;
2. No built-in support for parsing an integer or a string into an enum
value. This is how I implement my own parsing method.
/// Converts [input], which is an integer or a string, into an enum
value of
/// type [enumType].
/// Returns `null` if fails.
parseEnum(input, Type enumType) {
try {
var values = reflectClass(enumType).getField(#values).reflectee;
if (input is int) {
return values[input];
}
for (var value in values) {
if (value.toString().split('.')[1] == input) {
return value;
}
}
} catch (e) {
}
return null;
}
So, will the Dart team resolve these limitations in the next version of
the language?
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

[Sean Eagan]

Post by Man Hoang
As far as I can see, there are two big limitations of enum at the moment.
1. No easy way to know if an object is an enum (of and kind)
var isEnum = (value ! null) && reflectClass(value.runtimeType).isEnum;
// In C#, it's so easy
// var isEnum = value is Enum;

As with your limitation 2, it is currently supported only via mirrors:

https://api.dartlang.org/1.12.1/dart-mirrors/ClassMirror/isEnum.html

[Günter Zöchbauer]

Some comment recently indicates that they are considering extending enum
capabilities eventually.

I would add
- custom values for items.
- flags
(http://stackoverflow.com/questions/8447/what-does-the-flags-enum-attribute-mean-in-c)
- mirror-less access to the names

Using a normal class as enum (http://stackoverflow.com/a/15854550/217408)
isn't too cumbersome.
I usually just use a class because I can customize it to my likings.

Post by Man Hoang
As far as I can see, there are two big limitations of enum at the moment.
1. No easy way to know if an object is an enum (of and kind)
var isEnum = (value ! null) && reflectClass(value.runtimeType).isEnum;
// In C#, it's so easy
// var isEnum = value is Enum;
2. No built-in support for parsing an integer or a string into an enum
value. This is how I implement my own parsing method.
/// Converts [input], which is an integer or a string, into an enum
value of
/// type [enumType].
/// Returns `null` if fails.
parseEnum(input, Type enumType) {
try {
var values = reflectClass(enumType).getField(#values).reflectee;
if (input is int) {
return values[input];
}
for (var value in values) {
if (value.toString().split('.')[1] == input) {
return value;
}
}
} catch (e) {
}
return null;
}
So, will the Dart team resolve these limitations in the next version of
the language?

['Lasse R.H. Nielsen' via Dart Misc]

Post by Man Hoang
As far as I can see, there are two big limitations of enum at the moment.
1. No easy way to know if an object is an enum (of and kind)
var isEnum = (value ! null) && reflectClass(value.runtimeType).isEnum;
// In C#, it's so easy
// var isEnum = value is Enum;

Just for clarification: In which cases do you need to know that a value is
an instance of a class created using "enum"?
The interface is minuscule (.index) and the index isn't that useful if you
don't know the type, and since the methods on those are static, there isn't
a lot to use it for.

Post by Man Hoang
2. No built-in support for parsing an integer or a string into an enum
value. This is how I implement my own parsing method.
/// Converts [input], which is an integer or a string, into an enum
value of
/// type [enumType].
/// Returns `null` if fails.
parseEnum(input, Type enumType) {
try {
var values = reflectClass(enumType).getField(#values).reflectee;
if (input is int) {
return values[input];
}
for (var value in values) {
if (value.toString().split('.')[1] == input) {
return value;
}
}
} catch (e) {
}
return null;
}

As with so many other things, if you know the type statically, you can go
through the EnumType.values list.
If you don't know the type statically, then it's effectively reflection.
Using a Type value to represent something is ... rarely useful. If you had
an "EnumParser" class that you could instantiate with the values list, then
that would be a much better representation of the enum than its Type obejct.

An approach that could probably work, without clobbering the enum's
namespace, is to have an Enum superclass with static helper methods. Then
you could do "is Enum" and "Enum.getValues(someEnumValue)", and internally
it would just be one more (private, slightly magical) getter on each enum
class.

Post by Man Hoang
So, will the Dart team resolve these limitations in the next version of
the language?

I haven't heard of anything related to this. Can't speak for anybody else :)

/L
--
Lasse R.H. Nielsen - ***@google.com
'Faith without judgement merely degrades the spirit divine'
Google Denmark ApS - Frederiksborggade 20B, 1 sal - 1360 KÞbenhavn K
- Denmark - CVR nr. 28 86 69 84

[Don Olmstead]

I've just had two annoyances with enums. First one is you can't annotate a
value https://github.com/dart-lang/sdk/issues/23441

The other annoyance and this kinda goes back to the flags thing which
honestly I'd prefer if Dart followed C# there as you can just annotate that
its a flag and the magic happens, is that you can't do something like

class Flags<T extends Enum>

Other than that don't change a thing ;)

On Wed, Sep 16, 2015 at 9:19 AM, 'Lasse R.H. Nielsen' via Dart Misc <

Post by 'Lasse R.H. Nielsen' via Dart Misc

Post by Man Hoang
As far as I can see, there are two big limitations of enum at the moment.
1. No easy way to know if an object is an enum (of and kind)
var isEnum = (value ! null) && reflectClass(value.runtimeType).isEnum
;
// In C#, it's so easy
// var isEnum = value is Enum;

Just for clarification: In which cases do you need to know that a value is
an instance of a class created using "enum"?
The interface is minuscule (.index) and the index isn't that useful if you
don't know the type, and since the methods on those are static, there isn't
a lot to use it for.

Post by Man Hoang
2. No built-in support for parsing an integer or a string into an enum
value. This is how I implement my own parsing method.
/// Converts [input], which is an integer or a string, into an enum
value of
/// type [enumType].
/// Returns `null` if fails.
parseEnum(input, Type enumType) {
try {
var values = reflectClass(enumType).getField(#values).reflectee;
if (input is int) {
return values[input];
}
for (var value in values) {
if (value.toString().split('.')[1] == input) {
return value;
}
}
} catch (e) {
}
return null;
}

As with so many other things, if you know the type statically, you can go
through the EnumType.values list.
If you don't know the type statically, then it's effectively reflection.
Using a Type value to represent something is ... rarely useful. If you had
an "EnumParser" class that you could instantiate with the values list, then
that would be a much better representation of the enum than its Type obejct.
An approach that could probably work, without clobbering the enum's
namespace, is to have an Enum superclass with static helper methods. Then
you could do "is Enum" and "Enum.getValues(someEnumValue)", and internally
it would just be one more (private, slightly magical) getter on each enum
class.

Post by Man Hoang
So, will the Dart team resolve these limitations in the next version of
the language?

I haven't heard of anything related to this. Can't speak for anybody else :)
/L
--
'Faith without judgement merely degrades the spirit divine'
Google Denmark ApS - Frederiksborggade 20B, 1 sal - 1360 KÞbenhavn K
- Denmark - CVR nr. 28 86 69 84
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

[Man Hoang]

On Wednesday, September 16, 2015 at 11:20:25 PM UTC+7, Lasse Reichstein

Post by 'Lasse R.H. Nielsen' via Dart Misc

Post by Man Hoang
As far as I can see, there are two big limitations of enum at the moment.
1. No easy way to know if an object is an enum (of and kind)
var isEnum = (value ! null) && reflectClass(value.runtimeType).isEnum
;
// In C#, it's so easy
// var isEnum = value is Enum;

Just for clarification: In which cases do you need to know that a value is
an instance of a class created using "enum"?
The interface is minuscule (.index) and the index isn't that useful if you
don't know the type, and since the methods on those are static, there isn't
a lot to use it for.

I need to know this so I can correctly encode the value during JSON
serialization. This can be easily achieved by making sure that every enum
extends a special class called Enum (or whatever the name).

if (value is Enum) return value.index;
// or
if (value is Enum) return value.toString().split('.')[1];

Regarding the *toString* method, I think it would be better if an enum has
an instance method or a getter that returns only the name of the enum field.
This is because, in most cases, only the field name is used in JSON
serialization.

enum Color { blue, green, red }

Color.green.toString() == 'Color.green';

// Consider adding this method.
Color.green.toSimpleString() == 'green';

// Or consider adding this getter.
Color.green.name == 'green';


2. No built-in support for parsing an integer or a string into an enum

Post by 'Lasse R.H. Nielsen' via Dart Misc

Post by Man Hoang
value. This is how I implement my own parsing method.
/// Converts [input], which is an integer or a string, into an enum
value of
/// type [enumType].
/// Returns `null` if fails.
parseEnum(input, Type enumType) {
try {
var values = reflectClass(enumType).getField(#values).reflectee;
if (input is int) {
return values[input];
}
for (var value in values) {
if (value.toString().split('.')[1] == input) {
return value;
}
}
} catch (e) {
}
return null;
}

This is required when decoding a JSON string.

[Monty Rasmussen]

Yes, because of the way enums have been implemented in Dart, I pretty much just never use them. Too often, I need to serialize and persist data, and these int-based, ordinal enums are too hard to deal with. It's just about the only feature I truly dislike in Dart.

[David Morgan ☯]

Until language support improves,

https://github.com/google/enum_class.dart

should do what you want. It has "name" for ->string and "valueOf" for
conversion back from string.

And, all of them extend "EnumClass" :)

Post by Man Hoang
On Wednesday, September 16, 2015 at 11:20:25 PM UTC+7, Lasse Reichstein

Post by 'Lasse R.H. Nielsen' via Dart Misc

Post by Man Hoang
As far as I can see, there are two big limitations of enum at the moment.
1. No easy way to know if an object is an enum (of and kind)
var isEnum = (value ! null) && reflectClass(value.runtimeType).
isEnum;
// In C#, it's so easy
// var isEnum = value is Enum;

Just for clarification: In which cases do you need to know that a value
is an instance of a class created using "enum"?
The interface is minuscule (.index) and the index isn't that useful if
you don't know the type, and since the methods on those are static, there
isn't a lot to use it for.

I need to know this so I can correctly encode the value during JSON
serialization. This can be easily achieved by making sure that every enum
extends a special class called Enum (or whatever the name).
if (value is Enum) return value.index;
// or
if (value is Enum) return value.toString().split('.')[1];
Regarding the *toString* method, I think it would be better if an enum
has an instance method or a getter that returns only the name of the enum
field.
This is because, in most cases, only the field name is used in JSON
serialization.
enum Color { blue, green, red }
Color.green.toString() == 'Color.green';
// Consider adding this method.
Color.green.toSimpleString() == 'green';
// Or consider adding this getter.
Color.green.name == 'green';
2. No built-in support for parsing an integer or a string into an enum

Post by 'Lasse R.H. Nielsen' via Dart Misc

Post by Man Hoang
value. This is how I implement my own parsing method.
/// Converts [input], which is an integer or a string, into an enum
value of
/// type [enumType].
/// Returns `null` if fails.
parseEnum(input, Type enumType) {
try {
var values = reflectClass(enumType).getField(#values).reflectee;
if (input is int) {
return values[input];
}
for (var value in values) {
if (value.toString().split('.')[1] == input) {
return value;
}
}
} catch (e) {
}
return null;
}

This is required when decoding a JSON string.

[tatumizer-v0.2]

Yeah, "const" is a pita. If you need a proof, look no further than this
example.
We need a code generator and a lot of boilerplate and complexity just for
constness sake.

If language removed the requirement of constness in annotations and
elsewhere, we would be perfectly fine with "final" vars:
class TestEnum extends EnumClass {
static final
yes = new TestEnum._("yes"),
no = new TestEnum._("no"),
maybe = new TestEnum._("maybe");

TestEnum._(String name) : super(name);
}


That's all. There's very minimal amount of redundancy here; considering
that enums are quite rare, we could live with that IMO.

If you need the list of values, call Enums.values(TestEnum);
for "valueOf", call Enums.valueOf(TestEnum,"maybe");

BTW, it's not obvious that you need enums values to be "const", even with
current language design. (I can't immediately find a good use case that
requires constness).

['John Messerly' via Dart Misc]

Post by tatumizer-v0.2
BTW, it's not obvious that you need enums values to be "const", even with
current language design. (I can't immediately find a good use case that
requires constness).

They need to be const to be consumed by other constants, like metadata
annotations.

(Whether or not `const` should exist at all is separate question :) )

['Bob Nystrom' via Dart Misc]

Post by tatumizer-v0.2
BTW, it's not obvious that you need enums values to be "const", even with
current language design. (I can't immediately find a good use case that
requires constness).

The language specifies that a static warning must be reported if a switch()
on an enum type does not have a case for every value (or a default case).
That means at static analysis time, we need to know the full list of enum
values, and we need to be able to evaluate the expressions in the cases.

(Of course, if we wanted to allow non-const enums, this warning could be
removed and then this problem is no more.)

Cheers!

- bob

[tatumizer-v0.2]

Post by 'Bob Nystrom' via Dart Misc
The language specifies that a static warning must be reported if a

switch() on an enum type does not have a case for every value (or a default
case).
Oh, right, I forgot about this feature. Maybe because it's forgettable.
It's based on static type of selector, it should be enum for this magic to
work. If it's just "var" - nothing happens, even when "propagated type" is
enum.
I played a bit with short examples, and noticed something unusual. If
static type is enum, switch doesn't allow for possibility of null value of
selector. E.g.
enum MyEnum {
foo,bar
}
void main() {
MyEnum x=null;
switch (x) {
case MyEnum.foo:
case MyEnum.bar:
case null: // *error: Case expressions must have the same types,
'null' is not a 'MyEnum'*
// null is not MyEnum? why?
}
}
However, if selector is int, nulls are allowed:
void main() {
int x=null;
switch (x) {
case null: // *no problem!*
}
}

Strange...

[Gen]

I have tested things in Webstorm and my results are different from yours:
- I have no warning when I do not cover all enum values in a "switch"
statement.
- When I try "case null" for an "int" variable in Webstorm then I get this
error:
error: line 10 pos 8: expected case expression of type int
case null: print("int null");

I find it rather strange that one can assign "null" to a variable of type X
but
one can not match "null" as expression of type X for a "switch" statement.

Post by tatumizer-v0.2

Post by 'Bob Nystrom' via Dart Misc
The language specifies that a static warning must be reported if a

switch() on an enum type does not have a case for every value (or a default
case).
Oh, right, I forgot about this feature. Maybe because it's forgettable.
It's based on static type of selector, it should be enum for this magic to
work. If it's just "var" - nothing happens, even when "propagated type" is
enum.
I played a bit with short examples, and noticed something unusual. If
static type is enum, switch doesn't allow for possibility of null value of
selector. E.g.
enum MyEnum {
foo,bar
}
void main() {
MyEnum x=null;
switch (x) {
case null: // *error: Case expressions must have the same types,
'null' is not a 'MyEnum'*
// null is not MyEnum? why?
}
}
void main() {
int x=null;
switch (x) {
case null: // *no problem!*
}
}
Strange...

['Lasse R.H. Nielsen' via Dart Misc]

Post by Gen
- I have no warning when I do not cover all enum values in a "switch"
statement.
- When I try "case null" for an "int" variable in Webstorm then I get this
error: line 10 pos 8: expected case expression of type int
case null: print("int null");
I find it rather strange that one can assign "null" to a variable of type
X but
one can not match "null" as expression of type X for a "switch" statement.

The spec for switch is a little "special" on this point.

It requires all the switch constants to have the same type.
Not be assignable to the same type, or having a common supertype, but to

Post by Gen
It is a compile-time error if the values of the expressions e_k are not
• instances of the same class C, for all k ∈ 1..n, or
• instances of a class that implements int, for all k ∈ 1..n, or
• instances of a class that implements String, for all k ∈ 1..n.

It's not even a warning, it's a compile-time error if the values are not
all instances of the same class (or string or int, which is confusing
because we go to great lengths to avoid exposing that there are internal
subclasses of into or String, so the user would assume that all integers or
strings are already the same class).

It's also a compile time error if the class overrides Object's operator==
(except for a slew of exceptions for internal types that override
operator== but really feel like they shouldn't).

Basically, it's a mess.

We should at least remove the "same class" requirement since it prevents
you from using your own enum-like constants if you use a subclass for some
instances. The "not overriding operator==" probably has to stay so we can
use "identical" for the comparisons with good conscience.

/L
--
Lasse R.H. Nielsen - ***@google.com
'Faith without judgement merely degrades the spirit divine'
Google Denmark ApS - Frederiksborggade 20B, 1 sal - 1360 KÞbenhavn K
- Denmark - CVR nr. 28 86 69 84

[kc]

Post by David Morgan ☯
Until language support improves,
https://github.com/google/enum_class.dart

Re language support. Your work on enums, immutability/value objects is very
interesting.

Syntax/semantic innovation is being considered for Dart 2.0.

The React style diff-a-tree-of-value-objects does seem to be pretty central
to both Sky/Flutter and Angular 2.0. Support baked-in to the lang and
runtime would be good.

K.

[Alex Tatumizer]

I used dartpad for my etudes, but I can't figure out which version of dart
compiler is there. All I know is that dartpad accepts the following
program, no questions asked:
void main() {
int x=0;
switch (x) {
case null:
}
}

['Devon Carew' via Dart Misc]

Post by Alex Tatumizer
I used dartpad for my etudes, but I can't figure out which version of dart
compiler is there.

It's not documented, but to find out the version of the sdk that dartpad is
built on, click on the 'DartPad' text in the upper left. Right now it's
using 1.12.1.

All I know is that dartpad accepts the following program, no questions

Post by Alex Tatumizer
void main() {
int x=0;
switch (x) {
}
}
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

--
Devon Carew
Software Engineer
Google, Inc.

[tatumizer-v0.2]

Aha! Here's what happens.
This is valid:
void main() {
int x=0;
switch (x) {
case null:
}
}
But this is not:
void main() {
int x=0;
switch (x) {
case 0:
case null: //* error: Case expressions must have the same types, '0' is
not a 'Null'*
}
}

Dart just requires that all actual "cases" to be of the same type. So
"null" *alone* is treated as OK case (because there's nothing it can
conflict with).
Compare with java spec (maybe written by Gilad?)
Quote:
The prohibition against using null as a case constant prevents code being
written that can never be executed. If the switch statement's *Expression*
is of a reference type, that is, String or a boxed primitive type or an
enum type, *then an exception will be thrown will occur if the Expression
evaluates to null* at run time. In the judgment of the designers of the
Java programming language, this is a better outcome than silently skipping
the entire switch statement or choosing to execute the statements (if any)
after the default label (if any).
End Quote

In dart, exception is NOT thrown if Expression evaluates to null. I think
it undermines the logic behind special treatment of enum in a context of
switch statement.
The following is a valid dart program, it compiles and runs (in 1.12.1)
enum MyEnum {
foo
}
void main() {
MyEnum x=null;
switch (x) {
case MyEnum.foo:
}
print("OK"); // no error thrown for x=null - really prints OK
}

Requirement of "full set of enum values in switch" kind of makes sense
(IMO) only if the cases really exhaust the possibilities for Expression. If
we leave a loophole for x=null, then our list of variants is not complete.
Java cleverly avoids this pitfall by throwing NPE upfront when
Expression==null
Won't it be a good idea for dart to do the same?

['Lasse R.H. Nielsen' via Dart Misc]

Post by tatumizer-v0.2
Aha! Here's what happens.
void main() {
int x=0;
switch (x) {
}
}
void main() {
int x=0;
switch (x) {
case null: //* error: Case expressions must have the same types, '0'
is not a 'Null'*
}
}
Dart just requires that all actual "cases" to be of the same type. So
"null" *alone* is treated as OK case (because there's nothing it can
conflict with).
Compare with java spec (maybe written by Gilad?)
The prohibition against using null as a case constant prevents code being
written that can never be executed. If the switch statement's *Expression*
is of a reference type, that is, String or a boxed primitive type or an
enum type, *then an exception will be thrown will occur if the Expression
evaluates to null* at run time. In the judgment of the designers of the
Java programming language, this is a better outcome than silently skipping
the entire switch statement or choosing to execute the statements (if
any) after the default label (if any).
End Quote
In dart, exception is NOT thrown if Expression evaluates to null. I think
it undermines the logic behind special treatment of enum in a context of
switch statement.

I can see the point, but I'm not sure Dart and Java should be the same.
In Java, if the (static) type of a switch expression is Foo, then you know
that the result is either Foo or null.
In Dart, the result may be any value, even in checked mode.

The special handling of enums in a switch is to ensure that all enum values
are accounted for.
In Java, allowing null would mean that to be complete, you need to handle
null as well.
In Dart, you are never complete if you don't have a default case, and it's
not fixed by just disallowing null.

Dart is different from Java in that `null` is an object. Disallowing null
is special-casing that one object, and even if we wanted to, we can't do it
based on the static type like Java does because static types should not
affect runtime (and can't, the VM doesn't implement static analysis at all).

Well, we can actually do it, because we have ensured that all the case
expressions have the same class, so we can use that as a guide.

Post by tatumizer-v0.2
The following is a valid dart program, it compiles and runs (in 1.12.1)
enum MyEnum {
foo
}
void main() {
MyEnum x=null;
switch (x) {
}
print("OK"); // no error thrown for x=null - really prints OK
}

So is this:

enum MyEnum {foo}
abstract class C {
MyEnum get x;
}
class D implements C {
get x => 42;
}
void main() {
C c = new D();
switch (c.x) { // static type of c.x: MyEnum, actual value: 42, no type
errors in checked mode.
case MyEnum.foo:
}
print("OK"); // no error thrown for x=42. Would you expect one?
}

Post by tatumizer-v0.2
Requirement of "full set of enum values in switch" kind of makes sense
(IMO) only if the cases really exhaust the possibilities for Expression.

It doesn't, and while it's possible, it's not a small change.
It makes switches on enum classes (and maybe int and string as well, as in
Java) special in that they *throw* on a non-matching value, instead of
going to the default.

Post by tatumizer-v0.2
If we leave a loophole for x=null, then our list of variants is not
complete.

We leave a loophole for *all* value. There is no single exception like in
Java, we have to disallow all non-MyEnum values, which is possible (it's
detectable that the "class of the case expressions" is an enum class, and
default to throwing if the switch expression doesn't evaluate to an
instance of that class), but that would be a much more intrusive special
casing than just giving a warning if not all enum values are handled, and I
don't think the result is worth the complexity.

Java cleverly avoids this pitfall by throwing NPE upfront when

Post by tatumizer-v0.2
Expression==null
Won't it be a good idea for dart to do the same?

I don't think so. It's not enough, and I think doing enough to ensure
switch completeness is too much.

But then, I subscribe to the idea that switch statements are symptoms of a
bad OO design to begin with. You should use method dispatch instead - and
enums should be able to have methods for exactly that reason. Or tables, if
your values are really froma a small set of simple value.
Simple enums like what we have is just begging for switching by value, they
are actively encouraging bad design.

/L
--
Lasse R.H. Nielsen - ***@google.com
'Faith without judgement merely degrades the spirit divine'
Google Denmark ApS - Frederiksborggade 20B, 1 sal - 1360 KÞbenhavn K
- Denmark - CVR nr. 28 86 69 84

[Gen]

Post by 'Lasse R.H. Nielsen' via Dart Misc
But then, I subscribe to the idea that switch statements are symptoms of a
bad OO design to begin with. You should use method dispatch instead - and
enums should be able to have methods for exactly that reason. Or tables, if
your values are really froma a small set of simple value.
Simple enums like what we have is just begging for switching by value,
they are actively encouraging bad design.

AFAIU, a "switch" statement is an optimized version of "if" and "else if"
statements. These statements deal with values or objects.
I do not understand how method dispatch and enums with methods would affect
the "switch" statement.


Am Mittwoch, 30. September 2015 12:04:48 UTC+2 schrieb Lasse Reichstein

Post by 'Lasse R.H. Nielsen' via Dart Misc

Post by tatumizer-v0.2
Aha! Here's what happens.
void main() {
int x=0;
switch (x) {
}
}
void main() {
int x=0;
switch (x) {
case null: //* error: Case expressions must have the same types, '0'
is not a 'Null'*
}
}
Dart just requires that all actual "cases" to be of the same type. So
"null" *alone* is treated as OK case (because there's nothing it can
conflict with).
Compare with java spec (maybe written by Gilad?)
The prohibition against using null as a case constant prevents code
being written that can never be executed. If the switch statement's
*Expression* is of a reference type, that is, String or a boxed
primitive type or an enum type, *then an exception will be thrown will
occur if the Expression evaluates to null* at run time. In the judgment
of the designers of the Java programming language, this is a better outcome
than silently skipping the entire switch statement or choosing to
execute the statements (if any) after the default label (if any).
End Quote
In dart, exception is NOT thrown if Expression evaluates to null. I think
it undermines the logic behind special treatment of enum in a context of
switch statement.

I can see the point, but I'm not sure Dart and Java should be the same.
In Java, if the (static) type of a switch expression is Foo, then you know
that the result is either Foo or null.
In Dart, the result may be any value, even in checked mode.
The special handling of enums in a switch is to ensure that all enum
values are accounted for.
In Java, allowing null would mean that to be complete, you need to handle
null as well.
In Dart, you are never complete if you don't have a default case, and it's
not fixed by just disallowing null.
Dart is different from Java in that `null` is an object. Disallowing null
is special-casing that one object, and even if we wanted to, we can't do it
based on the static type like Java does because static types should not
affect runtime (and can't, the VM doesn't implement static analysis at all).
Well, we can actually do it, because we have ensured that all the case
expressions have the same class, so we can use that as a guide.

Post by tatumizer-v0.2
The following is a valid dart program, it compiles and runs (in 1.12.1)
enum MyEnum {
foo
}
void main() {
MyEnum x=null;
switch (x) {
}
print("OK"); // no error thrown for x=null - really prints OK
}

enum MyEnum {foo}
abstract class C {
MyEnum get x;
}
class D implements C {
get x => 42;
}
void main() {
C c = new D();
switch (c.x) { // static type of c.x: MyEnum, actual value: 42, no
type errors in checked mode.
}
print("OK"); // no error thrown for x=42. Would you expect one?
}

Post by tatumizer-v0.2
Requirement of "full set of enum values in switch" kind of makes sense
(IMO) only if the cases really exhaust the possibilities for Expression.

It doesn't, and while it's possible, it's not a small change.
It makes switches on enum classes (and maybe int and string as well, as in
Java) special in that they *throw* on a non-matching value, instead of
going to the default.

Post by tatumizer-v0.2
If we leave a loophole for x=null, then our list of variants is not
complete.

We leave a loophole for *all* value. There is no single exception like in
Java, we have to disallow all non-MyEnum values, which is possible (it's
detectable that the "class of the case expressions" is an enum class, and
default to throwing if the switch expression doesn't evaluate to an
instance of that class), but that would be a much more intrusive special
casing than just giving a warning if not all enum values are handled, and I
don't think the result is worth the complexity.
Java cleverly avoids this pitfall by throwing NPE upfront when

Post by tatumizer-v0.2
Expression==null
Won't it be a good idea for dart to do the same?

I don't think so. It's not enough, and I think doing enough to ensure
switch completeness is too much.
But then, I subscribe to the idea that switch statements are symptoms of a
bad OO design to begin with. You should use method dispatch instead - and
enums should be able to have methods for exactly that reason. Or tables, if
your values are really froma a small set of simple value.
Simple enums like what we have is just begging for switching by value,
they are actively encouraging bad design.
/L
--
'Faith without judgement merely degrades the spirit divine'
Google Denmark ApS - Frederiksborggade 20B, 1 sal - 1360 KÞbenhavn K
- Denmark - CVR nr. 28 86 69 84

[Alex Tatumizer]

@Lasse:
Sure, where java checks Expression != null, dart (in theory) should check
"Expression is of the same runtime type as all "case" variants. And maybe
it's too much. But then, specialcasing enum in switch (which is what dart
does now) is too much, too.

I'd like to clarify one point though: it's about the complexity of
implementing this check (no matter whether the feature is worthwhile or not
- just in theory). It might be complicated because VM doesn't know the
common type of "case" variants? But how it can generate optimal code
without this knowledge? E.g., suppose I have a switch with 42 variants
(say, 0..41) - then, good compiler will generate a jump table, instead of
if -else is -...etc. You can generate jump table only if you know the type
is int and check that the range is "dense". There are other optimization
techniques for "switch" - they all require the knowledge of type anyway.

But if compiler knows the expected type, generating the above check is no
more complicated than java's expression != null.

Post by Gen
I do not understand how method dispatch and enums with methods would

affect the "switch" statemen

When you have enums like in those in java, where enum values can be
objects, you just define extra method in the enum class, and call it *instead
*of writing switch. That's much cleaner. "switch" is quite rarely needed,
mostly in very low-level functions like scanner or something. That's
another reason I think too much fuss about types in switch is unwarranted:
the feature is too rare and reserved mostly for low-level scenarios. (it
has to be optimized really well by compiler, not blindly generating if
-else if ...).

[Gen]

Can you give an example how a method could replace a "switch" statement ?
Maybe you want to replace this:
switch (enum):
case enum.A : object.someMethod();break;
by this:
enum.someMethod();

Obviously what enum.someMethod() does depends on the enum and not on method
that would like to call object.someMethod() and not enum.someMethod().
I do not see how one can replace "if" or "switch" by a method dispatch.

Post by Alex Tatumizer
Sure, where java checks Expression != null, dart (in theory) should check
"Expression is of the same runtime type as all "case" variants. And maybe
it's too much. But then, specialcasing enum in switch (which is what dart
does now) is too much, too.
I'd like to clarify one point though: it's about the complexity of
implementing this check (no matter whether the feature is worthwhile or not
- just in theory). It might be complicated because VM doesn't know the
common type of "case" variants? But how it can generate optimal code
without this knowledge? E.g., suppose I have a switch with 42 variants
(say, 0..41) - then, good compiler will generate a jump table, instead of
if -else is -...etc. You can generate jump table only if you know the type
is int and check that the range is "dense". There are other optimization
techniques for "switch" - they all require the knowledge of type anyway.
But if compiler knows the expected type, generating the above check is no
more complicated than java's expression != null.

Post by Gen
I do not understand how method dispatch and enums with methods would

affect the "switch" statemen
When you have enums like in those in java, where enum values can be
objects, you just define extra method in the enum class, and call it *instead
*of writing switch. That's much cleaner. "switch" is quite rarely needed,
mostly in very low-level functions like scanner or something. That's
the feature is too rare and reserved mostly for low-level scenarios. (it
has to be optimized really well by compiler, not blindly generating if
-else if ...).

[Alex Tatumizer]

@Gen: normally, this doesn't happen. If you know any real use case, we can
look into it. (I never encountered such situation before, but it doesn't
mean it doesn't exist. I so far used switches only in a low-level context,
and even that is rare).

[tatumizer-v0.2]

Oh, I think I know what you mean.
Java provides special syntax for defining extra methods for each enum
individually.
In dart, you can model it like this:
class TestEnum extends EnumClass {
static final
yes = new TestEnum._("yes", ()=>"Mr. Yes"),
no = new TestEnum._("no", ()=>"I don't even know who I am"),
maybe = new TestEnum._("maybe", ()=>"call me 'maybe'");
Function _whoAreYou;
TestEnum._(String name, this._whoAreYou) : super(name);
String whoAreYou()=>_whoAreYou();
}


Or you can subclass TestEnum, having 3 different subclasses for yes, no and
maybe.
Then, instead of switching, just call myEnum.whoAreYou();
In dart, this all is quite concise, not sure it would warrant any special
syntax.

['Lasse R.H. Nielsen' via Dart Misc]

This post might be inappropriate. Click to display it.

['David "Morgan" Morgan' via Dart Misc]

Post by 'Lasse R.H. Nielsen' via Dart Misc
My problem is that Java enums allow you to use dispatch instead of switch
by allowing you to add methods to the enum objects, and even individual
methods to each object.
Dart enums only support switching, which is kindof sad.

It is. And here's that link again ;)

https://github.com/google/enum_class.dart

It might not be super pretty, but it's the best we have. My team uses it
extensively. Actually an older, google-internal implementation, but we'll
switch to this one in time.

[Gen]

@tatumizer-v0.2 @Lasse Reichstein Holst Nielsen

Thanks for the explanations and I agree with you except that a "switch"
could be replaced by a method dispatch.

IMO, these ideas are essential:

That uses method dispatch to select which code to run, like a switch does,

Post by 'Lasse R.H. Nielsen' via Dart Misc
but puts it on the objects themselves instead of in some unrelated function
elsewhere.

That is what I had written and that is the whole point of using "if" and
"switch" instead of an abstract method dispatch: Call elsewhere some other
function depending on a certain case.
With "if" and "switch" and "for", the caller or interpreter can know the
case and decide what is done in that case.

Post by 'Lasse R.H. Nielsen' via Dart Misc
You can't do that for integers or strings, or just classes that you're not
writing yourself, which is why switching on integers may make sense (but
only if you are not using the integers to represent objects - in that case
you should use the object itself). A scanner is the typical example where
you want to switch on an plain input code point.

Integers, strings, enumerations, "symbols" and even collections are
"readable" values that one can use in combination with "if" and "switch"
and "for" statements.

Of course an enumeration is technically an object which could have useful
convenience and dispatch methods.
But the purpose of "if" and "switch" is to statically link a certain case
to a certain consequence within a method.
Whereas object orientation and dynamic method dispatch is useful to keep
things abstract and dynamic within a method.
But somewhere abstraction must end and that is where "if" and "switch" or
other pattern matching mechanisms are used.


Am Donnerstag, 1. Oktober 2015 07:59:55 UTC+2 schrieb Lasse Reichstein

Post by 'Lasse R.H. Nielsen' via Dart Misc

Post by Gen
Can you give an example how a method could replace a "switch" statement ?

A switch, at its core, detects one of a number of cases and executes code
depending on which case it is.
In Dart, switch cases can only be compile-time constant objects of the
same type, so the matched values will have a common supertype. It's a
multi-way branch with trivial branching logic (so there is no hidden
computation in the branching, it's all in the case code)..
That means that the "code depending on the case" can be put into a method
on the constant object instead.
floom(Biff biff) {
switch (biff) {
case Biff.boff: something(); break;
case Biff.fluff: somethingElse(); break;
}
}
floom(Biff biff) { biff.floom(); }
where Biff.boff.floom is floom() { something(); } and Bif.fluff.floom is
floom() { somethingElse(); } .
That uses method dispatch to select which code to run, like a switch does,
but puts it on the objects themselves instead of in some unrelated function
elsewhere.
This has some advantages and some disadvantages, but it is usually easier
(to some degree) to maintain something written using dynamic dispatch than
something using switch statements.
It keeps the "object related operation" on the object, which is good for
locality.
It does require you to have control over the Biff class in order to add
the floom method.
You can't do that for integers or strings, or just classes that you're not
writing yourself, which is why switching on integers may make sense (but
only if you are not using the integers to represent objects - in that case
you should use the object itself). A scanner is the typical example where
you want to switch on an plain input code point.
If the switch is basically on the type of an object, that object should do
it for you. If the operation is not something you can predict ahead of
time, you can use double-dispatch (visitor pattern) instead.

Post by Gen
case enum.A : object.someMethod();break;
enum.someMethod();
Obviously what enum.someMethod() does depends on the enum and not on
method that would like to call object.someMethod() and not
enum.someMethod().
I do not see how one can replace "if" or "switch" by a method dispatch.

http://c2.com/cgi/wiki?SwitchStatementsSmell
My problem is that Java enums allow you to use dispatch instead of switch
by allowing you to add methods to the enum objects, and even individual
methods to each object.
Dart enums only support switching, which is kindof sad.
/L
--
'Faith without judgement merely degrades the spirit divine'
Google Denmark ApS - Frederiksborggade 20B, 1 sal - 1360 KÞbenhavn K
- Denmark - CVR nr. 28 86 69 84

[KwangYul Seo]

I would like to add one more

* Make enum types implement Comparable.

Currently, we can't use enum values as keys in sorted map like SplayTreeMap
because enums do not implement Comparable.

https://dartpad.dartlang.org/2521edbafa15ee40b702

Post by Man Hoang
As far as I can see, there are two big limitations of enum at the moment.
1. No easy way to know if an object is an enum (of and kind)
var isEnum = (value ! null) && reflectClass(value.runtimeType).isEnum;
// In C#, it's so easy
// var isEnum = value is Enum;
2. No built-in support for parsing an integer or a string into an enum
value. This is how I implement my own parsing method.
/// Converts [input], which is an integer or a string, into an enum
value of
/// type [enumType].
/// Returns `null` if fails.
parseEnum(input, Type enumType) {
try {
var values = reflectClass(enumType).getField(#values).reflectee;
if (input is int) {
return values[input];
}
for (var value in values) {
if (value.toString().split('.')[1] == input) {
return value;
}
}
} catch (e) {
}
return null;
}
So, will the Dart team resolve these limitations in the next version of
the language?
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

[David Morgan ☯]

Please have a look at

https://github.com/google/enum_class.dart

for cases when you want to do class-like things with enums, such as
implementing Comparable. It also gives you conversion to/from string via
"name" and "valueOf". Suggestions for other functionality to add are
welcome, please file them as issues.

EnumClass is intended to be the "we'd like Dart enums to be as powerful as
Java ones" dropin library until language support improves. So, if you need
support for something now, you may want to file an issue for EnumClass,
it's likely to arrive a lot faster than a change to the Dart language :)

Cheers

Morgan

Post by KwangYul Seo
I would like to add one more
* Make enum types implement Comparable.
Currently, we can't use enum values as keys in sorted map like
SplayTreeMap because enums do not implement Comparable.
https://dartpad.dartlang.org/2521edbafa15ee40b702

Post by Man Hoang
As far as I can see, there are two big limitations of enum at the moment.
1. No easy way to know if an object is an enum (of and kind)
var isEnum = (value ! null) && reflectClass(value.runtimeType).isEnum
;
// In C#, it's so easy
// var isEnum = value is Enum;
2. No built-in support for parsing an integer or a string into an enum
value. This is how I implement my own parsing method.
/// Converts [input], which is an integer or a string, into an enum
value of
/// type [enumType].
/// Returns `null` if fails.
parseEnum(input, Type enumType) {
try {
var values = reflectClass(enumType).getField(#values).reflectee;
if (input is int) {
return values[input];
}
for (var value in values) {
if (value.toString().split('.')[1] == input) {
return value;
}
}
} catch (e) {
}
return null;
}
So, will the Dart team resolve these limitations in the next version of
the language?
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an