View source for Talk:Enums in Eiffel

You do not have permission to edit this page, for the following reasons:

The action you have requested is limited to users in one of the groups: Autoconfirmed users, emailconfirmed, editors.
You must confirm your email address before editing pages. Please set and validate your email address through your user preferences.

You can view and copy the source of this page:

--[[User:Peter gummer|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?

--[[User:Paulb|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.

--[[User:Colin-adams|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.

--[[User:Paulb|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:

<code>[eiffel]
enum class
    BORDER_STYLE

feature -- Access

    none: NATURAL = 1
    flat: NATURAL = 2
    rounded: NATURAL = 3
    embossed: NATURAL = 4

end
</code>

The compiler could inference the Enum entity type from its members, in the example case <code>[eiffel]NATURAL</code>. 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.

--[[User:Peter gummer|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:

<code>[eiffel]
enum class
    BORDER_STYLE

feature -- Access

    none, flat, rounded, embossed

end
</code>

A different approach, however, rather than saying that <code>[eiffel]BORDER_STYLE</code> ''is'' an enum, would be to say that <code>[eiffel]BORDER_STYLE</code> ''has'' an enum:

<code>[eiffel]
class
    BORDER_STYLE

feature -- Access

    none, flat, rounded, embossed: ENUM [NATURAL]

end
</code>

This avoids the difficulty of knowing which features are meant to be part of the enum, in the event of other features being declared in <code>[eiffel]BORDER_STYLE</code> or its descendants. Rather than introducing a new keyword, several features are declared as the class's enum constants. (It's a bit like the old obsolete <code>[eiffel]unique</code> keyword.) The yucky thing about this is that the compiler would have to magically recognise <code>[eiffel]ENUM</code> as a special class.

Return to Talk:Enums in Eiffel.

Retrieved from "https://dev.eiffel.com/Talk:Enums_in_Eiffel"

View source for Talk:Enums in Eiffel

Navigation

Development

Wiki

Search

Tools