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.  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.
+
Requesting comments on the notion of an implicit class.  
  
−
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 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'
−
 
−
The second part would be to allow non-attribute features to be added to the implicit class.
 
−
 
−
<eiffel>
 
−
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
 
−
</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.
 
−
 
−
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 11: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'

Retrieved from "https://dev.eiffel.com/index.php?title=Implicit_class&oldid=9831"