Talk:Enums in Eiffel

--Peter gummer 04:07, 4 May 2007 (CEST) This is a great article, Paul. I'm frequently amazed at how often I encounter INTEGER used in situations where (coming from C, Delphi and C#) I would have expected an enum. Your example is amazing; this habit of using INTEGER is even worse than I realised!

But there is one other problem with using INTEGER that you haven't mentioned, and it's actually the problem that I encounter most frequently. As the user of a library, writing code to use something like EV_TEXT_ALIGNABLE is difficult because I cannot use code completion to discover instantly what values are allowed. I have to figure it out laboriously by studying the class and then studying another class.

One thing I don't understand (and maybe this is because "This Page is Under Development") is why do we need language support for enums? EV_TEXT_ALIGNMENT is just a class. We could write EV_TEXT_ALIGNMENT today with all of the benefits that you've shown. Would the only benefit of language support be to make enums easier to write? This in itself is worthwhile if it reduces the use of INTEGER.

Would Eiffel enums be expanded? Would they be frozen, like C# enums?

--Paulb 06:46, 4 May 2007 (CEST) Peter, the article is in it's infancy and it's not even got complete sections or articles. I'm working on all explaining the issues and providing examples. I'll be working more on it tomorrow and hopefully have a first draft ready.

I understand what you are saying about EV_TEXT_ALIGNMENT. In EiffelEnvision, which is written in Eiffel for .NET now I have crafted fake Enums in Eiffel, so it's proof that it can be done. However, it's a lot of work to create a fake Enum and there is a lot of code. The good thing is that they work in inspect statements and you can statically access the members. Having language support would make allow Enums to be written quickly and provides additional support by implementing some features. I used static access to `item' in an example of Enum types, which is impossible in Eiffel right now. Although a proposal for static Eiffel routines (not attributes) is also something I have in the works and I believe is desperately needed.

In answer to you final questions, yes Enums would probably have expanded semantics but unlike other languages they will no be frozen. Extending Enums I think is important. However Enums will most likely not have conforming inheritance.

--Colin-adams I would change the name of the class from ENUM to ENUMERATION.

What would language support look like? I would be perfectly happy just to have ENUMERATION added to ELKS.

--Paulb 18:08, 9 May 2007 (CEST) The idea is that the type would actually be hidden anyway, if there is language support. I cannot give you an idea what it would look like because this is something we are going to have to take up with the ECMA committee.

Suffice to say, in its simplest form it could look like this:

enum class
    BORDER_STYLE
 
feature -- Access
 
    none: NATURAL = 1
    flat: NATURAL = 2
    rounded: NATURAL = 3
    embossed: NATURAL = 4
 
end

The compiler could inference the Enum entity type from its members, in the example case NATURAL. Validity rules could ensure that each member is of the same type.

Colin, can you please use --(tilda)(tilda)(tilda)(tilda) when adding comments. If you don't your comments are blurred into those of a previous commenter. There is even a signature button (second from the right) to add it for you.

--Peter gummer 04:43, 10 May 2007 (CEST) That's still more complicated than what we do in other languages. Usually when defining an enum type in other languages, we don't need to specify the constant values (1, 2, 3, 4), nor their type. The compiler could generate these automatically. So its simplest form could look like this:

enum class
    BORDER_STYLE
 
feature -- Access
 
    none, flat, rounded, embossed
 
end

A different approach, however, rather than saying that BORDER_STYLE is an enum, would be to say that BORDER_STYLE has an enum:

class
    BORDER_STYLE
 
feature -- Access
 
    none, flat, rounded, embossed: enum
 
end

Several features are declared as the class's enum constants. This makes it easy to see which features are meant to be part of the enum, in the event of other features being declared in BORDER_STYLE or its descendants. (It's a bit like the old obsolete unique keyword.)

--Colin-adams 08:33, 10 May 2007 (CEST)If the signature should always be added, why doesn't the software do that?

And stop using "enum"! We don't use "int", we have "INTEGER".

--Pgc 10:36, 10 May 2007 (CEST) I do not agree using the feature keyword to express enumeration values. We should speak of "enumerated" classes. An enumeration defines the set of instances (domain of the class) and attaches a name (for human readability) to each instance. If we really want to provide type safety and also provide an efficient way of interfacing to legacy systems, it should be possible to convert an instance of an enumerated class to/from some base type value(integer, string, ...).

Here is a tentative syntax for enumerated classes. New keyword : 'enumerated'. Enumeration of possible instances is done via the 'create' keyword. Each keyword appearing in the create list is an identifier for each instance of the enumerated class; no procedure must be defined.

enumerated class
    BORDER_STYLE
 
create
    none, 
    flat, 
    rounded, 
    embossed
 
end

In user code, {BORDER_STYLE}.none denotes the 'none' instance of BORDER_STYLE.

--Peter gummer 16:32, 10 May 2007 (CEST) Yes, that's nice, Paul-Georges. (That is you, Monsieur Crismer?) The rationale for using the create keyword is that enumeration identifiers are, in a sense, factory methods. It's an interesting thought, that leads me to wonder whether this could be generalised to provide factory functions (something that Eiffel sorely lacks) without the evils of static routines that other languages suffer from. If you add static routines to an OO language, most programmers use them, backsliding into procedural programming, and those of us who know it's bad practice are forever engaged in a battle against it. Factory functions are, in my experience, the only legitimate use of static routines, and it would be great if a syntax similar to your proposal could give us that.

But they are singleton factory methods. So rather than create, maybe it would be better to use once:

enumerated class
    BORDER_STYLE
 
once
    none, 
    flat, 
    rounded, 
    embossed
 
end

Or, rather than abuse an existing keyword, we could remove the enumerated keyword from before class, and place it before the enumeration identifiers:

class
    BORDER_STYLE
 
enumerate
    none, 
    flat, 
    rounded, 
    embossed
 
end