Difference between revisions of "Implicit class"
(Cosmetics) |
|||
Line 5: | Line 5: | ||
The basic idea of the first idea would be performing the exact same functionality as the `Renaming' clause in formal generic constraints. Instead of defining the multiple conformance inline within the text of the class containing the formal generic that is constrained, the generic would have its own class file. | The basic idea of the first idea would be performing the exact same functionality as the `Renaming' clause in formal generic constraints. Instead of defining the multiple conformance inline within the text of the class containing the formal generic that is constrained, the generic would have its own class file. | ||
− | < | + | <eiffel> |
implicit class A | implicit class A | ||
inherit | inherit | ||
Line 17: | Line 17: | ||
end | end | ||
end | end | ||
− | </ | + | </eiffel> |
− | < | + | <eiffel> |
class CONTAINER [G -> A] | class CONTAINER [G -> A] | ||
end | end | ||
− | </ | + | </eiffel> |
would be identical to ECMA | would be identical to ECMA | ||
− | < | + | <eiffel> |
class CONTAINER [G -> {B rename is_equal as b_is_equal end, C rename is_equal as b_is_equal_end}] | class CONTAINER [G -> {B rename is_equal as b_is_equal end, C rename is_equal as b_is_equal_end}] | ||
end | end | ||
− | </ | + | </eiffel> |
Any class inheriting from B and C would automatically inherit from A. This simple change would facilitate clarity and reuse in formal generic parameters. | Any class inheriting from B and C would automatically inherit from A. This simple change would facilitate clarity and reuse in formal generic parameters. | ||
Line 37: | Line 37: | ||
The second part would be to allow non-attribute features to be added to the implicit class. | The second part would be to allow non-attribute features to be added to the implicit class. | ||
− | < | + | <eiffel> |
implicit class STRING_EXTRA | implicit class STRING_EXTRA | ||
inherit | inherit | ||
Line 47: | Line 47: | ||
result := count \\ 5 = 0 or count \\ 7 = 0 | result := count \\ 5 = 0 or count \\ 7 = 0 | ||
end | end | ||
− | </ | + | </eiffel> |
Any string class could be downcast to a STRING_EXTRA and would allow the new call length_multiple_of_5_or_7 to be called. | Any string class could be downcast to a STRING_EXTRA and would allow the new call length_multiple_of_5_or_7 to be called. | ||
This would allow new operations to be defined as a composition of existing operations on objects from existing libraries in a type-safe way at compile time(I think). This way instead of the client, CLIENT, of the STRING class needing to define the new length operation in its own class, CLIENT.length_multiple_of_5_or_7(string: STRING):BOOLEAN, the system can be more correctly designed to attach the new length operation to the STRING_EXTRA class and CLIENT can become a client of the STRING_EXTRA class instead just plain STRING. This would allow longer reuse of existing libraries without recompiling the library until the STRING class can be updated to include the new operation or forever if the new operation is problem domain specific. | This would allow new operations to be defined as a composition of existing operations on objects from existing libraries in a type-safe way at compile time(I think). This way instead of the client, CLIENT, of the STRING class needing to define the new length operation in its own class, CLIENT.length_multiple_of_5_or_7(string: STRING):BOOLEAN, the system can be more correctly designed to attach the new length operation to the STRING_EXTRA class and CLIENT can become a client of the STRING_EXTRA class instead just plain STRING. This would allow longer reuse of existing libraries without recompiling the library until the STRING class can be updated to include the new operation or forever if the new operation is problem domain specific. |
Revision as of 17:58, 2 October 2007
Research: This page describes research about Eiffel, not the actual language specification.
Requesting comments on the notion of an implicit class. There are two parts to this. The first part is a very simple way to make easy use of multiple constraints. The second part is more complex but I think can still all be done at compile time.
The basic idea of the first idea would be performing the exact same functionality as the `Renaming' clause in formal generic constraints. Instead of defining the multiple conformance inline within the text of the class containing the formal generic that is constrained, the generic would have its own class file.
implicit class A inherit B rename is_equal as b_is_equal end C rename is_equal as c_is_equal end end
class CONTAINER [G -> A] end
would be identical to ECMA
class CONTAINER [G -> {B rename is_equal as b_is_equal end, C rename is_equal as b_is_equal_end}] end
Any class inheriting from B and C would automatically inherit from A. This simple change would facilitate clarity and reuse in formal generic parameters.
This would also allow multiple constraints to be easily adaptable to actual generic parameters. container: LIST[A] would allow features of B and C to be called on objects inside of `container' using the renaming policy defined in `A'
The second part would be to allow non-attribute features to be added to the implicit class.
implicit class STRING_EXTRA inherit STRING feature length_multiple_of_5_or_7: BOOLEAN is do result := count \\ 5 = 0 or count \\ 7 = 0 end
Any string class could be downcast to a STRING_EXTRA and would allow the new call length_multiple_of_5_or_7 to be called.
This would allow new operations to be defined as a composition of existing operations on objects from existing libraries in a type-safe way at compile time(I think). This way instead of the client, CLIENT, of the STRING class needing to define the new length operation in its own class, CLIENT.length_multiple_of_5_or_7(string: STRING):BOOLEAN, the system can be more correctly designed to attach the new length operation to the STRING_EXTRA class and CLIENT can become a client of the STRING_EXTRA class instead just plain STRING. This would allow longer reuse of existing libraries without recompiling the library until the STRING class can be updated to include the new operation or forever if the new operation is problem domain specific.