Difference between revisions of "Implicit class"
m |
(Focusing on one idea.) |
||
Line 1: | Line 1: | ||
{{Research}} | {{Research}} | ||
− | Requesting comments on the notion of an implicit class | + | Requesting comments on the notion of an implicit class. |
− | The basic | + | The basic 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> | <eiffel> | ||
Line 34: | Line 34: | ||
This would also allow multiple constraints to be easily adaptable to actual generic parameters. | This would also allow multiple constraints to be easily adaptable to actual generic parameters. | ||
container: LIST[A] would allow objects inheriting from B and C to be placed in `container' and features in B and C to be called on these objects inside of `container' using the renaming policy defined in `A' | container: LIST[A] would allow objects inheriting from B and C to be placed in `container' and features in B and C to be called on these objects inside of `container' using the renaming policy defined in `A' | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− |
Revision as of 12:18, 3 October 2007
Research: This page describes research about Eiffel, not the actual language specification.
Requesting comments on the notion of an implicit class.
The basic 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 objects inheriting from B and C to be placed in `container' and features in B and C to be called on these objects inside of `container' using the renaming policy defined in `A'