enumerations and constants

[privat]

Currently there is no way to express enumeration and constants.

This is a limitation of the language and users are complaining!

I created a new page with the current known workarounds. You can review or add your own if you wish http://nitlanguage.org/faq/constants_and_enumerations.html

Note: should I tag the issue v1.0prealpha?

[ablondin]

Since one can declare variables (var), functions (fun), classes and interfaces, why not add a keyword const or cons to Nit when declaring constants? It would essentially be the same as a variable, with the same visibility rules, except that one could not modify the content.

[jcbrinfo]

This keyword may be val like Scala, Kotlin, etc. so it would has the same length than var and fun.

[jpages]

Les énumérations, ça me semble important. Je pense qu'il faut ajouter ça de base pour la version 1.0, c'est quand même une fonctionnalité de base et bien pratique.

Les workaround "Enumerations as Int" et "Enumerations a singleton objects", deux ont tous les deux des avantages même si la deuxième forme est peut-être plus élégante mais coûteuse... J'aime pas la troisième forme car ce n'est pas utilisable avec l'interpréteur. Une fonctionnalité aussi basique que ça doit être disponible partout.

Pour les constantes, pareil c'est la base je pense qu'il faut avoir ça pour la v1.0, surtout que encore une fois ça ne coûte pas très cher à rajouter. Comme @jcbrinfo je pense que le val est une bonne idée si c'est bien fait (pas comme en Scala).

À mon avis, const et cons ont des connotations dans d'autres langages (en C++ et en Scheme) qui peuvent poser problème car le programmeur peut s'embrouiller.

Pour résumer, les workarounds ont assez souvent le qualificatif "ugly" dans la page liée, il faudrait peut-être fournir une solution propre aux développeurs. Surtout que ça ne coûte pas cher à implémenter et ça nettoierai la librairie.

[ablondin]

+1 for val instead of cons/const.

I also agree that enumerations should be done before 1.0. Considering the implementation, it should probably be with integers in the background (for efficiency purpose), but with compilation errors if one tries to use an enumeration instance as an integer.

[lbajolet]

Why not both ?

We could extend the grammar for the support of enumerations, a proposition of syntax could be something like (fun fact, the enum keyword is already reserved, yay !):

enum BasicEnum is
    x0, x1, x2
end

Enumerations could be typed by Int implicitely by default, unless a programmer decides to change its type, in which case values will require to be input manually.

Something in the lines of

enum TypedEnum of String is
    x0 = "X0"
    x1 = "X1"
    x2 = "X2"
end

or, as equivalent to the example above

enum BasicEnum of Int is
    x0 = 0
    x1 = 1
    x2 = 2
end

The val could be facultative in these cases, I included it just because, but this does not mean it must be there in the end.

I don't know how useful this might be, but should we support enumeration redefs ?

[privat]

The syntax

enum Foo is
  foo, bar, baz
end

will cause issue with the parser because it conflicts with annotations.

Now my point of view:

There is different approaches of enumeration in languages. But, I am not fan of making enum some special subtype of Int (or String), I prefer to see things in a pure OO way where objects are things, and classes just categories of objects.

For me, what differentiate an enum from a standard concrete class is the following:

• instances of enums are managed by the system (no new)
• instances of enums are immutable (no mutable attributes)

In fact these rules are already enforced by the tools since they allow kernel to declare Int, Bool, and cie. as enum and avoid that peoples add a constructor or an attribute in those classes by refinement.

Previously, the keyword universal was used instead on enum to state that those objects are some kind magically constant and accessible instances (but still objects). The renaming was done a long time ago for the reason that enum will be more understandable than universal for the reader 21e38157917068fc920a057bc6c170be5dfe2bda`

A related idea was to add some kind of universal objects that does not particularly belong to a enum with other elements; one way to imagine them is as some kind of enum singleton. Such objects could be very usefull when one do need only behavior (and optionally identity) but no state. Eg the various top-level onced method that returns a pure behavioral object like default_comparator.

One can compare this idea with the object keyword of scala except that I do not like that these objects could contain mutable fields that cause the isolation to be broken.

(still thinking aloud) now with only these singleton/immutable object, one can simulate finite enumerations

interface Color # This will be the enumeration in fact
   fun rgb: String is abstract
   fun complement: Color is abstract
end

object blue # assume that the `object` keyword declare/create those universal immutable objects
   super Color
   redef fun rgb do return "#0000ff"
   redef fun complement do return orange
end

object orange
   super Color
   redef fun rgb do return "#ffff00"
   redef fun complement do return blue
end

object gray
   super Color
   redef fun rgb do return "7f7f7f"
   redef fun complement do return self
end

The previous is only a possible model, one can KISS it with some kind of syntactic sugar maybe.

In fact, I am not really sure of how this is going nor what is the best abstraction. Let's hear about ideas of other people :)

[Morriar]

I like the proposal @privat.

Speaking of the syntax, I like the idea of Java where all enum objects are stored in the enum. It's more easy to read and understand what are the possible values of the enum compared to the syntax you gave.

[jcbrinfo]

@privat Please update the link to the FAQ in your first message. The URL is now http://nitlanguage.org/faq/constants_and_enumerations.html. Thanks.

[privat]

@jcbrinfo done