Difference between revisions of "Implicit class"

(Focusing on one idea.)
Line 30: Line 30:
 
</eiffel>
 
</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 could be downcast to 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.
 
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 14:06, 20 November 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 could be downcast to 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'