Implicit class

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

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.