Difference between revisions of "Enums in Eiffel"
(→Why Does Eiffel Need an Enum Type) |
|||
Line 8: | Line 8: | ||
==Why Does Eiffel Need an Enum Type== | ==Why Does Eiffel Need an Enum Type== | ||
+ | The reasons are numerous and leaves us asking why they were not approached in the ECMA specification. | ||
+ | |||
+ | As Eiffel evolves and rears its head into the mainstream, its application domain expands. Users, libraries and complexity all grows as a languages does. It has been long said that Eiffel is almost unique in its ability to self-document classes and routines through terse comments and contracts. However, Eiffel for being so terse with commenting, is extremely verbose with class interfaces which can be trying at times. | ||
+ | |||
+ | ===Enums for Brevity=== | ||
+ | To demonstrate a point of Eiffel's verboseness, due to the lack of an Enum type specification, turn you eyes to <code>[eiffel]EV_TEXT_ALIGNABLE</code>: | ||
+ | |||
+ | <code>[eiffel] | ||
+ | deferred class | ||
+ | EV_TEXT_ALIGNABLE | ||
+ | |||
+ | feature -- Access | ||
+ | |||
+ | text_alignment: INTEGER is | ||
+ | -- Current alignment. | ||
+ | -- See class EV_TEXT_ALIGNABLE_CONSTANTS for | ||
+ | -- possible values. | ||
+ | require | ||
+ | not_destroyed: not is_destroyed | ||
+ | ensure | ||
+ | bridge_ok: Result = implementation.text_alignment | ||
+ | |||
+ | feature -- Status report | ||
+ | |||
+ | is_left_aligned: BOOLEAN is | ||
+ | -- Is `Current' left aligned? | ||
+ | require | ||
+ | not_destroyed: not is_destroyed | ||
+ | |||
+ | is_center_aligned: BOOLEAN is | ||
+ | -- Is `Current' center aligned? | ||
+ | require | ||
+ | not_destroyed: not is_destroyed | ||
+ | |||
+ | is_right_aligned: BOOLEAN is | ||
+ | -- Is `Current' right aligned? | ||
+ | require | ||
+ | not_destroyed: not is_destroyed | ||
+ | |||
+ | feature -- Status setting | ||
+ | |||
+ | align_text_center is | ||
+ | -- Display `text' centered. | ||
+ | require | ||
+ | not_destroyed: not is_destroyed | ||
+ | ensure | ||
+ | alignment_set: is_center_aligned | ||
+ | |||
+ | align_text_right is | ||
+ | -- Display `text' right aligned. | ||
+ | require | ||
+ | not_destroyed: not is_destroyed | ||
+ | ensure | ||
+ | alignment_set: is_right_aligned | ||
+ | |||
+ | align_text_left is | ||
+ | -- Display `text' left aligned. | ||
+ | require | ||
+ | not_destroyed: not is_destroyed | ||
+ | ensure | ||
+ | alignment_set: is_left_aligned | ||
+ | |||
+ | invariant | ||
+ | valid_alignment: | ||
+ | (create {EV_TEXT_ALIGNMENT_CONSTANTS}).valid_alignment (text_alignment) | ||
+ | |||
+ | end | ||
+ | </code> | ||
+ | |||
+ | In <code>[eiffel]EV_TEXT_ALIGNMENT</code> there is already is <code>[eiffel]text_alignment</code>, which exhibits the inherent problem with type saftey through the lack of an Enum type. No only is a flag attribute present but there are the status setting routines <code>[eiffel]align_text_left</code>, <code>[eiffel]align_text_right</code> and <code>[eiffel]align_text_center</code>. On top of that, for the sake of code clarity for clients there are the status queries <code>[eiffel]is_left_aligned</code>, <code>[eiffel]is_right_aligned</code> and <code>[eiffel]is_center_aligned</code>. The status setting and query routines hide the implementation details of having to know and use <code>[eiffel]EV_TEXT_ALIGNMENT_CONSTANTS</code>, which is a good thing but can also be very frustrating when writing effective code using this interface. | ||
+ | |||
+ | To demonstrate, assume a graphical editor has been developed using EiffelVision2. In the editor the user selects a region of text which should enabled tool bar button used to manipulate the alignment of the selected region to text. | ||
+ | |||
+ | <code>[eiffel] | ||
+ | on_text_selected | ||
+ | require | ||
+ | has_selection: has_selection | ||
+ | local | ||
+ | l_alignable: EV_TEXT_ALIGNABLE | ||
+ | do | ||
+ | l_alignable ?= selected_entity | ||
+ | if l_alignable /= Void then | ||
+ | if l_alignable.is_left_aligned then | ||
+ | active_button := left_aligned_button | ||
+ | elseif l_alignable.is_center_aligned then | ||
+ | active_button := center_aligned_button | ||
+ | elseif l_alignable.is_right_aligned then | ||
+ | active_button := right_aligned_button | ||
+ | else | ||
+ | -- New alignment not respect! | ||
+ | check False end | ||
+ | end | ||
+ | end | ||
+ | if active_button /= Void | ||
+ | alignment_button_group.set_active_button (active_button) | ||
+ | alignment_button_group.enable_sensitive | ||
+ | else | ||
+ | alignment_button_group.disable_sensitive | ||
+ | end | ||
+ | end | ||
+ | </code> | ||
+ | |||
+ | <code>[eiffel] | ||
+ | on_text_selected | ||
+ | |||
+ | </code> |
Revision as of 15:01, 3 May 2007
Preface
Something pondered for years was the question regarding why Eiffel has never embraced Enum types or a variant more in style with the Eiffel paradigm. There are a number of comments from numerous developers regarding why Enums are "Bad". Most languages exhibit bad ideals and some more than others. The congisen is that if you give a developer a tool to abuse it will be abused and sometimes by the seasoned developers. Generally, seasoned developers have a grasp of the dangers of abusing aspects of a language to gain performance or micro design. However lessons are learned from those who know better from those that know less. As such bad programming practices creep down the chain until it become a common convention.
In this document I'll outline the pontetial dangers and the oddities found commonly with the "Enum" type and attempt to dispell them with a solution to implementing Enums in Eiffel. First and foremost, Why does Eiffel need an Enum type...
Why Does Eiffel Need an Enum Type
The reasons are numerous and leaves us asking why they were not approached in the ECMA specification.
As Eiffel evolves and rears its head into the mainstream, its application domain expands. Users, libraries and complexity all grows as a languages does. It has been long said that Eiffel is almost unique in its ability to self-document classes and routines through terse comments and contracts. However, Eiffel for being so terse with commenting, is extremely verbose with class interfaces which can be trying at times.
Enums for Brevity
To demonstrate a point of Eiffel's verboseness, due to the lack of an Enum type specification, turn you eyes to EV_TEXT_ALIGNABLE
:
deferred class EV_TEXT_ALIGNABLE feature -- Access text_alignment: INTEGER is -- Current alignment. -- See class EV_TEXT_ALIGNABLE_CONSTANTS for -- possible values. require not_destroyed: not is_destroyed ensure bridge_ok: Result = implementation.text_alignment feature -- Status report is_left_aligned: BOOLEAN is -- Is `Current' left aligned? require not_destroyed: not is_destroyed is_center_aligned: BOOLEAN is -- Is `Current' center aligned? require not_destroyed: not is_destroyed is_right_aligned: BOOLEAN is -- Is `Current' right aligned? require not_destroyed: not is_destroyed feature -- Status setting align_text_center is -- Display `text' centered. require not_destroyed: not is_destroyed ensure alignment_set: is_center_aligned align_text_right is -- Display `text' right aligned. require not_destroyed: not is_destroyed ensure alignment_set: is_right_aligned align_text_left is -- Display `text' left aligned. require not_destroyed: not is_destroyed ensure alignment_set: is_left_aligned invariant valid_alignment: (create {EV_TEXT_ALIGNMENT_CONSTANTS}).valid_alignment (text_alignment) end
In EV_TEXT_ALIGNMENT
there is already is text_alignment
, which exhibits the inherent problem with type saftey through the lack of an Enum type. No only is a flag attribute present but there are the status setting routines align_text_left
, align_text_right
and align_text_center
. On top of that, for the sake of code clarity for clients there are the status queries is_left_aligned
, is_right_aligned
and is_center_aligned
. The status setting and query routines hide the implementation details of having to know and use EV_TEXT_ALIGNMENT_CONSTANTS
, which is a good thing but can also be very frustrating when writing effective code using this interface.
To demonstrate, assume a graphical editor has been developed using EiffelVision2. In the editor the user selects a region of text which should enabled tool bar button used to manipulate the alignment of the selected region to text.
on_text_selected require has_selection: has_selection local l_alignable: EV_TEXT_ALIGNABLE do l_alignable ?= selected_entity if l_alignable /= Void then if l_alignable.is_left_aligned then active_button := left_aligned_button elseif l_alignable.is_center_aligned then active_button := center_aligned_button elseif l_alignable.is_right_aligned then active_button := right_aligned_button else -- New alignment not respect! check False end end end if active_button /= Void alignment_button_group.set_active_button (active_button) alignment_button_group.enable_sensitive else alignment_button_group.disable_sensitive end end
on_text_selected