Talk:Enums in Eiffel - Revision history

Paulb at 17:13, 10 May 2007

2007-05-10T17:13:29Z

Peter gummer at 14:32, 10 May 2007

2007-05-10T14:32:38Z

Pgc at 08:36, 10 May 2007

2007-05-10T08:36:38Z

Colin-adams at 06:33, 10 May 2007

2007-05-10T06:33:26Z

Peter gummer at 04:23, 10 May 2007

2007-05-10T04:23:16Z

Peter gummer at 02:43, 10 May 2007

2007-05-10T02:43:07Z

Paulb at 16:08, 9 May 2007

2007-05-09T16:08:40Z

Paulb at 16:08, 9 May 2007

2007-05-09T16:08:06Z

Colin-adams at 06:59, 9 May 2007

2007-05-09T06:59:55Z

Paulb at 04:46, 4 May 2007

2007-05-04T04:46:27Z

← Older revision		Revision as of 17:13, 10 May 2007
Line 126:		Line 126:
	end		end
	</code>		</code>
		+
		+	--[[User:Paulb\|Paulb]] 19:13, 10 May 2007 (CEST) All these ideas are very good for the purpose of creating simple enumerated types in Eiffel. The more terse the declaration the better, as long as it's clear in it meaning. My only concern is that we probably need to create an enumerated type specification supporting complex enumerate types found in other languages. [[http://java.sun.com/j2se/1.5.0/docs/guide/language/enums.html This]] is a powerful implementation of enumerated types that Eiffel could expand upon.
		+
		+	My reasoning for no proposal of design to date is because we first need to define how powerful enumerated types should be.
		+
		+	Just a word about statics - this is something I would very much like to see in Eiffel. Before people start screaming at me, let me explain. I only want to see static functions and possibly static procedures. There are many cases where statics would improve design, which I hope to explain and highlight in the very near future. Statics in Eiffel is something I am going to be writing about very soon.

← Older revision		Revision as of 14:32, 10 May 2007
Line 93:		Line 93:

	In user code, <code>{BORDER_STYLE}.none</code> denotes the 'none' instance of <code>BORDER_STYLE</code>.		In user code, <code>{BORDER_STYLE}.none</code> denotes the 'none' instance of <code>BORDER_STYLE</code>.
		+
		+	--[[User:Peter gummer\|Peter gummer]] 16:32, 10 May 2007 (CEST)
		+	Yes, that's nice, Paul-Georges. (That is you, Monsieur Crismer?) The rationale for using the <code>[eiffel]create</code> 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 <code>[eiffel]create</code>, maybe it would be better to use <code>[eiffel]once</code>:
		+
		+	<code>[eiffel]
		+	enumerated class
		+	BORDER_STYLE
		+
		+	once
		+	none,
		+	flat,
		+	rounded,
		+	embossed
		+
		+	end
		+	</code>
		+
		+	Or, rather than abuse an existing keyword, we could remove the <code>[eiffel]enumerated</code> keyword from before <code>[eiffel]class</code>, and place it before the enumeration identifiers:
		+
		+	<code>[eiffel]
		+	class
		+	BORDER_STYLE
		+
		+	enumerate
		+	none,
		+	flat,
		+	rounded,
		+	embossed
		+
		+	end
		+	</code>

← Older revision		Revision as of 08:36, 10 May 2007
Line 72:		Line 72:

	And stop using "enum"! We don't use "int", we have "INTEGER".		And stop using "enum"! We don't use "int", we have "INTEGER".
		+
		+	--[[User:Pgc\|Pgc]] 10:36, 10 May 2007 (CEST)
		+	I do not agree using the <code>feature</code> 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.
		+
		+	<e>
		+	enumerated class
		+	BORDER_STYLE
		+
		+	create
		+	none,
		+	flat,
		+	rounded,
		+	embossed
		+
		+	end
		+	</e>
		+
		+	In user code, <code>{BORDER_STYLE}.none</code> denotes the 'none' instance of <code>BORDER_STYLE</code>.

← Older revision		Revision as of 06:33, 10 May 2007
Line 68:		Line 68:

	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.)		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.)
		+
		+	--[[User:Colin-adams\|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".

@@ Line 62: / Line 62: @@
 feature -- Access
-     none, flat, rounded, embossed: ENUM [NATURAL]
+     none, flat, rounded, embossed: enum
 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.
+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.)

← Older revision		Revision as of 02:43, 10 May 2007
Line 40:		Line 40:

	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.		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.

@@ Line 21: / Line 21: @@
 --[[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:
+Suffice to say, in its simplest form it could look like this:
 <code>[eiffel]

@@ Line 15: / Line 15: @@
 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.
-I would change the name of the class from ENUM to ENUMERATION.
+--[[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.

← Older revision		Revision as of 06:59, 9 May 2007
Line 14:		Line 14:

	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.		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.
		+
		+	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.

← Older revision		Revision as of 04:46, 4 May 2007
Line 8:		Line 8:
	Would Eiffel enums be expanded? Would they be frozen, like C# enums?		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.