EnumClass should support instance fields

[davidmorgan]

There doesn't seem to be any nice syntax possible for this, but it should be available as an option.

[davidmorgan]

Didn't figure out a nice way to do this. You can already effectively do it yourself by forwarding to whatever values you want, e.g.

class MyEnum {
  MyActualEnum _instance => switch(this) { case FOO: return foo; case BAR: return bar; }

  String get value1 => _instance.value1;
  String get value2 => _instance.value2;
}

This is awkward, but any combination of generated code and enums with fields turns out to be awkward. Suggestions appreciated.

[wangyizhuo]

What about allow adding constructor param like Java?

Recently working with audience_sub_type.dart in google3 making me missing Java. We can easily change methods with switch statement to instance fields in constructor. It is easier to read and you won't forget adding switch case to any of the methods.

[davidmorgan]

Unfortunately adding a constructor param is pretty awkward. Currently we can generate constants with names for you, so the amount of boilerplate you have to write is limited:

  static const TestEnum yes = _$yes;
  static const TestEnum no = _$no;
  static const TestEnum maybe = _$maybe;

But if you add a constructor parameter that changes, you then have to supply the name yourself:

  final String description;
  const TestEnum._(String name, {this.description}) : super(name);

  static const TestEnum yes = const TestEnum('yes', description: 'desc1');
  static const TestEnum no = const TestNum('no', description: 'desc2');
  static const TestNum maybe = const TestEnum('maybe', description: 'desc3');

In the end I think it might be neater to just create a sibling class and delegate to it. This also has the advantage that the impl can have non-const fields, whereas with an enum you're restricted to just const values.

To be clear, this is the pattern I think is worth trying:

class TestEnum {

  _TestEnumImpl get _impl => switch(this) { case yes: return yesImpl; ...}
  String description => _impl.description;
}

_TestEnumImpl yesImpl = new _TestEnumImpl(description: 'desc1');

class _TestEnumImpl {
  final String description;
  TestEnumImpl(this.description);
}

[wangyizhuo]

I agree sibling class would work, but I'd rather prefer to supply the name instead of writing a switch statement.

I don't like switch method because it's error prone.

[davidmorgan]

I think the const restrictions are more of an issue. For example, you can't call any methods or getters.

I notice that audience_sub_type is using i18n strings; the compiler won't let you make these fields on an enum because they're not 'const'. So for this case, the delegation I describe is the only way to do it, I'm afraid.

[wangyizhuo]

Agree that we can only use const in param. In this case, we can have a hybrid of constructor params + switch method. I still feel it's better than the sibling class. Probably because I am coming from Java.

[davidmorgan]

Don't get me wrong, I'd definitely like to support it. The whole point of EnumClass, really, is to be as close to a Java enum as possible.

I just haven't seen a way yet that I think is significantly better than doing nothing at all. The extra complexity and caveats that would go with adding field support are pretty bad -- when EnumClass is already rather awkward to use.

One thing we might be able to do later -- with analyzer plugins -- is to warn you on missing values in a 'switch' statement for switches over an EnumClass. Then, at least, that problem would be avoided. (It'd also provide some safety for general use of EnumClass, not just in implementing your EnumClass methods).

[bencalabrese]

Not that this is less awkward (maybe just a different flavor of awkward?) but const parameters could get passed in via annotations on the different enum values.

  final String description;
  const TestEnum._(String name, {this.description}) : super(name);
  
  @$TestEnumParams(description: 'desc1')
  static const TestEnum yes = _$yes;

  @$TestEnumParams(description: 'desc2')
  static const TestEnum no = _$no;

  @$TestEnumParams(description: 'desc3')
  static const TestNum maybe = _$maybe;

Here, TestEnumParams is a generated container (with a const constructor) for the different parameters. Not sure that that alleviates any of the complexity concerns though. Turning those annotation parameters into generated code could be challenging for anything that isn't a primitive.

Could the parameters be reconstituted by *cringes a little* grabbing the source code of the annotation and basically copy/pasting the arguments from its constructor into the enum constructor?

[davidmorgan]

Yeah, I'd try copying the source directly; the generated part is in the same compilation context so it should just work.

Restricting to const params is the main downside I think.

My plan here is to wait for Dart 2 to land, maybe it will bring something we can use. If not, perhaps it's time to open a feature request :)