Implicit class - Revision history

Clemahieu at 01:29, 19 March 2008

2008-03-19T01:29:45Z

Clemahieu at 01:27, 19 March 2008

2008-03-19T01:27:58Z

Clemahieu at 16:38, 21 November 2007

2007-11-21T16:38:35Z

Clemahieu at 23:13, 20 November 2007

2007-11-20T23:13:15Z

Clemahieu at 23:12, 20 November 2007

2007-11-20T23:12:59Z

Clemahieu at 23:06, 20 November 2007

2007-11-20T23:06:33Z

Clemahieu: Focusing on one idea.

2007-10-03T20:18:25Z

Focusing on one idea.

Clemahieu at 04:31, 3 October 2007

2007-10-03T04:31:31Z

Manus: Cosmetics

2007-10-03T02:58:26Z

Cosmetics

Clemahieu at 18:50, 2 October 2007

2007-10-02T18:50:10Z

@@ Line 3: / Line 3: @@
 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.  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.
+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>
@@ Line 16: / Line 16: @@
 is_equal as c_is_equal
 end
 end
 </eiffel>

@@ Line 3: / Line 3: @@
 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.
+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.  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>
-implicit class A
+class A
 inherit
+B

@@ Line 33: / Line 33: @@
 local
    item: F
 do
-   {A}item.b_is_equals
+   val := {A}item.b_is_equals(void)
-   {A}item.c_is_equals
+   val := {A}item.c_is_equals(void)
 end
 </eiffel>

@@ Line 37: / Line 37: @@
    {A}item.c_is_equals
 end
 <eiffel>

@@ Line 18: / Line 18: @@
 end
 </eiffel>
 <eiffel>

@@ Line 30: / Line 30: @@
 </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.
 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'

@@ Line 5: / Line 5: @@
 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.
-<code>
+<eiffel>
 implicit class A
 inherit
@@ Line 17: / Line 17: @@
 end
 end
-</code>
+</eiffel>
-<code>
+<eiffel>
 class CONTAINER [G -> A]
 end
-</code>
+</eiffel>
 would be identical to ECMA
-<code>
+<eiffel>
 class CONTAINER [G -> {B rename is_equal as b_is_equal end, C rename is_equal as b_is_equal_end}]
 end
-</code>
+</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.
@@ Line 37: / Line 37: @@
 The second part would be to allow non-attribute features to be added to the implicit class.
-<code>
+<eiffel>
 implicit class STRING_EXTRA
 inherit
@@ Line 47: / Line 47: @@
        result := count \\ 5 = 0 or count \\ 7 = 0
      end
-</code>
+</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.