Difference between revisions of "Talk:Enums in Eiffel"
Peter gummer (Talk | contribs) |
Peter gummer (Talk | contribs) |
||
| Line 62: | Line 62: | ||
feature -- Access | feature -- Access | ||
| − | none, flat, rounded, embossed: | + | none, flat, rounded, embossed: enum |
end | end | ||
</code> | </code> | ||
| − | This | + | 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 <code>[eiffel]BORDER_STYLE</code> or its descendants. (It's a bit like the old obsolete <code>[eiffel]unique</code> keyword.) |
Revision as of 19:23, 9 May 2007
--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.)
