Difference between revisions of "Implicit class"

(Cosmetics)
 
(7 intermediate revisions by the same user not shown)
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 and allowing new features to be applied to an object without modifying the original class text.  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.  Any class that inherits from B and C could statically downcast that object to A.  A validity constraint on the downcast would be class A cannot contain new attributes.
  
 
<eiffel>
 
<eiffel>
−
implicit class A
+
class A
 
inherit
 
inherit
 
B
 
B
Line 16: Line 16:
 
is_equal as c_is_equal
 
is_equal as c_is_equal
 
end
 
end
 +
feature
 +
new_op: INTEGER is
 +
  do
 +
    result := b.val + c.val
 +
  end
 
end
 
end
 
</eiffel>
 
</eiffel>
  
 +
The following class:
 
<eiffel>
 
<eiffel>
−
class CONTAINER [G -> A]
+
class F
 +
inherit
 +
B
 +
C
 
end
 
end
 
</eiffel>
 
</eiffel>
  
−
would be identical to ECMA
+
Could then be used like:
 
<eiffel>
 
<eiffel>
−
class CONTAINER [G -> {B rename is_equal as b_is_equal end, C rename is_equal as b_is_equal_end}]
+
feature operation is
 +
local
 +
  item: F
 +
  container: LINKED_LIST[A]
 +
  val: BOOLEAN
 +
do
 +
  val := {A}item.b_is_equals(void)
 +
  val := {A}item.c_is_equals(void)
 +
  create container.make
 +
  container.put({A}item)
 
end
 
end
 
</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.
 
−
 
−
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.
 
  
 
<eiffel>
 
<eiffel>
−
implicit class STRING_EXTRA
+
class CONTAINER [G -> A]
−
inherit
+
end
−
  STRING
+
</eiffel>
  
−
feature
+
would be identical to ECMA
−
  length_multiple_of_5_or_7: BOOLEAN is
+
<eiffel>
−
    do
+
class CONTAINER [G -> {B rename is_equal as b_is_equal end, C rename is_equal as b_is_equal_end}]
−
      result := count \\ 5 = 0 or count \\ 7 = 0
+
end
−
    end
+
 
</eiffel>
 
</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.
+
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 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.
+
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'

Latest revision as of 16:29, 18 March 2008

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 and allowing new features to be applied to an object without modifying the original class text. 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. Any class that inherits from B and C could statically downcast that object to A. A validity constraint on the downcast would be class A cannot contain new attributes. 

class A
inherit
B
rename
is_equal as b_is_equal
end
C
rename
is_equal as c_is_equal
end
feature
new_op: INTEGER is
  do
    result := b.val + c.val
  end
end

The following class: 

class F
inherit
B
C
end

Could then be used like: 

feature operation is
local
  item: F
  container: LINKED_LIST[A]
  val: BOOLEAN
do
  val := {A}item.b_is_equals(void)
  val := {A}item.c_is_equals(void)
  create container.make
  container.put({A}item)
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'

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