Difference between revisions of "Implicit class"

Revision as of 14:12, 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

The following class:

class F
inherit
B
C
end

Could then be used like:

feature operation is
local
  item: F
do
  {A}item.b_is_equals
  {A}item.c_is_equals
end
 
<eiffel>
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'