Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enhancement: Enum #88

Closed
DartBot opened this issue Oct 12, 2011 · 19 comments

Comments

Projects
None yet
5 participants
@DartBot
Copy link

commented Oct 12, 2011

This issue was originally filed by carstenkl...@yahoo.de


I am missing a generic Enum<T> class like for example in Java.

Could this be included into the language please?

@DartBot

This comment has been minimized.

Copy link
Author

commented Oct 12, 2011

This comment was originally written by jat@google.com


There was discussion about it, but for the technology preview it was decided to leave it out and just use static final fields for now. It may be added later.


Removed Type-Defect label.
Added Type-Enhancement, Area-Language, Triaged labels.

@gbracha

This comment has been minimized.

Copy link
Contributor

commented Oct 12, 2011

Set owner to @gbracha.

@DartBot

This comment has been minimized.

Copy link
Author

commented Dec 5, 2011

This comment was originally written by bwuest...@gmail.com


I find Java's advanced enumerations very powerful over the alternative of defining static final fields. In addition to the type checking they provide and being able to iterate over the entire collection of values, being able to define fields for each type really helps code maintainability for many scenarios in my opinion. I would love to see a similar construct in dart down the road. Has this feature been added to any schedule or is this still simply on the "wish list?"

@danrubel

This comment has been minimized.

Copy link
Member

commented Dec 16, 2011

[anonymous user feedback]
Please add enums. Time to break out of c language hell

@DartBot

This comment has been minimized.

Copy link
Author

commented Mar 29, 2012

This comment was originally written by sorinm...@google.com


IMHO, Enums in Java cover two major language functionalities:

  1. Enforce type correctness. For example:

enum Gender {
  MALE,
  FEMALE
}

void createPerson(String name, Gender gender) { ... }

  1. Enclose functionality related to the type. For example:

enum UrlParameter {
  FIRST_NAME("firstName", true /* required /),
  BIRTHDAY("birthday", false /
required */);

  UrlParameter(String name, boolean isRequired) { ... }

  // ...

  boolean isRequired() {
    return isRequired;
  }
}

I feel that the second one is arguably leading to bad patterns (e.g. when Enums start making real work instead of delegating).

However, I feel that the first one (type safety) is necessary, otherwise the validity checks will end up being written by developers and executed at runtime.

@DartBot

This comment has been minimized.

Copy link
Author

commented Mar 29, 2012

This comment was originally written by ladicek@gmail.com


There are at least two other functions of enums: 1. communicating an API (if a function accepts only a restricted set of values, it's way better to make that argument an enum instead of an int), 2. restricting instantiability of a class (there can only be the specified instances of the enum class, no others).

@DartBot

This comment has been minimized.

Copy link
Author

commented Mar 29, 2012

This comment was originally written by sorinm...@google.com


@ladi...@gmail.com, I would like to add to your comments:

The "communicating an API" argument overlaps with what I was trying to explain by "type safety". Thank you for detailing this use case.

For restricting the instantiability of a class, my impression is that the Dart factory model should address this pattern better.

I guess the point I was trying to make was the following:
Since Dart is a young language, I agree that you don't want to get in it any features that have an awkward design (and will be hard to take back later). Enums in Java are quite complex to include in the first months of a language. But there is a core aspect to them (call it "type correctness" or "communicating an API"). This core aspect is a very powerful tool and I'd like to have it earlier rather than later.

@DartBot

This comment has been minimized.

Copy link
Author

commented Apr 22, 2012

This comment was originally written by rtimon...@gmail.com


What's wrong with

interface ConnectionState { }
class Connected implements ConnectionState { }
class Connecting implements ConnectionState { }
class Disconnected implements ConnectionState { }

//later
ConnectionState connectionState;
if (connectionState is Connecting) { ... }

@DartBot

This comment has been minimized.

Copy link
Author

commented Apr 22, 2012

This comment was originally written by ladicek@gmail.com


What's wrong with

interface ConnectionState { }
class Connected implements ConnectionState { }
class Connecting implements ConnectionState { }
class Disconnected implements ConnectionState { }

//later
ConnectionState connectionState;
if (connectionState is Connecting) { ... }

This 'if' is exactly what's wrong, you can't do a 'switch'. Enums are one of the few cases where switch is way better than if. Also, it's overly verbose, and would be even more verbose when you'd add const constructors, which would be necessary in a lot of times -- enum cases as compile time constants are a need.

@DartBot

This comment has been minimized.

Copy link
Author

commented Apr 22, 2012

This comment was originally written by amatiasq...@gmail.com


also with class inhetitance you can't limit the possible values with enum
you provide a set of values and nothing else will be accepted
El 22/04/2012 11:22, <dart@googlecode.com> escribi�

@DartBot

This comment has been minimized.

Copy link
Author

commented Apr 23, 2012

This comment was originally written by sorinm...@google.com


+1 on the previous two comments.

In addition to comment 10, I also believe there is value in being able to iterate through all possible values and validating that your code is handling all possible states, say in an unit test.

@anders-sandholm

This comment has been minimized.

Copy link
Contributor

commented Apr 30, 2012

Added apr30-triage label.

@DartBot

This comment has been minimized.

Copy link
Author

commented Apr 30, 2012

This comment was originally written by carstenkl...@yahoo.de


For a starter, perhaps have a look at the enumjs project hosted over at github.com, which implements a type safe, enumerable enum that can be used in for example switch statements and for simple comparisons between enum constants.

See github.com/axnsoftware/enumjs.

It was implemented using coffeescript, but can easily be ported to for example dart.

@anders-sandholm

This comment has been minimized.

Copy link
Contributor

commented May 1, 2012

Removed apr30-triage label.

@anders-sandholm

This comment has been minimized.

Copy link
Contributor

commented May 1, 2012

Added triage1 label.

@anders-sandholm

This comment has been minimized.

Copy link
Contributor

commented May 1, 2012

Let's up the priority on this one. Setting milestone to M1.


Added this to the M1 milestone.
Removed triage1 label.

@gbracha

This comment has been minimized.

Copy link
Contributor

commented May 1, 2012

Added Accepted label.

@DartBot

This comment has been minimized.

Copy link
Author

commented May 1, 2012

This comment was originally written by @seaneagan


One way to get enums without baking them into the language would be to define a "marker" interface possibly in a dart:enum library for enums to implement:

interface Enum {}

and then add the ability to mark classes as final (non-extensible). A class X which implements Enum would be checked by tools that it is final, has no public constructors, and defines a static values getter of type Set<X>:

final class Gender implements Enum {
  static final values = new Set<Gender>();

  static final MALE = new Gender.();
  static final FEMALE = new Gender.
();

  Gender._() => values.add(this);
}

Tools could also check in switch statements on expressions of type X, that there exist cases for all static final fields of X of type X.

This approach might allow for more flexibility in how to define enums.

@DartBot

This comment has been minimized.

Copy link
Author

commented May 1, 2012

This comment was originally written by @seaneagan


Actually, it would probably need to look more like the below due to lazy initialization of statics. This would be a good use case for Set literals:

final class Gender implements Enum {
  static final values = <Gender>[MALE, FEMALE];

  static final MALE = new Gender.();
  static final FEMALE = new Gender.
();

  Gender._();
}

This issue was closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.