Default and explicit variance - Revision history

Conaclos: Discard the extaended variant typing

2014-05-11T17:09:31Z

Discard the extaended variant typing

Conaclos: agent conformance update

2014-05-05T21:19:21Z

agent conformance update

Conaclos: ARgument and feature ambiguity solved

2014-03-03T17:10:59Z

ARgument and feature ambiguity solved

Conaclos: Minor improvements

2013-08-29T14:06:31Z

Minor improvements

Conaclos: Minor improvements

2013-08-29T13:47:54Z

Minor improvements

Conaclos: /* Limit change */

2013-05-20T10:13:03Z

‎Limit change

Conaclos: /* General discussions */

2013-05-20T10:12:34Z

‎General discussions

Conaclos: /* Right abstraction */

2013-05-18T18:28:46Z

‎Right abstraction

Conaclos: precisions

2013-05-18T18:26:45Z

precisions

Conaclos: listing

2013-05-18T18:07:57Z

listing

@@ Line 3: / Line 3: @@
 {{Research}}
 == Introduction ==
-In first the limited variant typing is exposed. It checks all catcall checkpoints.
+In first the variant typing is exposed. It checks all catcall checkpoints.
-In the second part the mechanism is extended. It is less simple and explicit, but it enables a best transition.
+In second the inroduced mechanism is compared against other.
-== Limited variant typing ==
+== Variant typing ==
 What is the advantages of covariance compared to a novariant typing?
 * explicit and adaptative interface
@@ Line 221: / Line 221: @@
 A possible critical could be the generic conformance restriction. Propositions are mentioned below.
 == General discussions ==
@@ Line 396: / Line 363: @@
 It passes all [[Catcall checkpoints]].
-The new generic conformance gives a natural safe and flexible static typing.
+The new generic conformance gives a natural, safe, and flexible static typing.
-The variant typing enables to create adaptive interfaces keeping a safe static typing.
+The variant typing allows to create adaptive interfaces keeping a safe static typing.
-With a fine abstraction and the use of variant typing for generics, the genric conformance flexibility is little restricted. The contravariant for request result can then be discarded for simplicity.
+With a fine abstraction and the use of variant typing for generics, the genric conformance flexibility is little restricted.
 There is no interface restriction ([[Interval types]] or [[Usage-site variance]]). Class interfaces are fully available.

@@ Line 174: / Line 174: @@
 The first is used in these features : 'target', 'is_equal', 'set_operands', 'copy', 'apply'
-'is_equal', 'set_operands' and 'copy' rely on data model.
+'is_equal', 'set_operands' and 'copy' and 'target' rely on data model.
-'apply' and 'target' are more sensitive. Indeed the problem is when there is an opened target.
+'apply' is more sensitive. Indeed the problem is when there is an opened target.
-'apply' could be restricted for no opened arguments.
+'apply' could be restricted for no opened arguments or could be removed since it is not a lot used.
 <e>
 apply
@@ Line 186: / Line 186: @@
 	end
 </e>
 The redesign of agent classes is an opportunity to solve agent problems (see [[Minor-ECMA-problems]], [[Agents in SCOOP]]).

@@ Line 19: / Line 19: @@
 === Feature redefinition ===
 * Covariant redefinition of request result is allowed (as currently).
-* Covariant redefinition of feature argument requires a variant typing on redefined feature or first feature definition.
+* Covariant redefinition of feature argument requires a variant typing on redefined argument or first definition.
-'''The most restrictive type''' for a variant type argument is the type of the first feature definition.
+'''The most restrictive type''' for a variant type argument is the type of the first definition.
 The first rule is a stronger postcondition. The current semantic is not changed.
-'''example 1:''' covariant redefinition of feature argument with 'variant' typing on redefined feature
+'''example 1:''' covariant redefinition of feature argument with 'variant' typing on redefined argument
 Note:

@@ Line 353: / Line 353: @@
 To limit code change and to increase typing consistency, we can change the semantic of 'variant'.
-Covariant redefinition of request result is not very useful.
+Contravariant redefinition of request result is not very useful.
 The variant typing could be limited for covariant redefinition. There could have no effect on request result.
 For generic conformance, a formal generic prefixed with the variant mark is covariant. The variant mark is not required on feature argument limiting code change.
-However we have a problem: How mark a contravariant generic? There is two options:
+However we have a problem: How mark a contravariant generic? There is three options:
 * Another mark.
 * No prefixed mark means novariant or contravariant generic

@@ Line 29: / Line 29: @@
 * The object test is not needed.
 * the type is not repeated in the object test.
-* In the interface of the current type the 'variant' is removed. Indeed, it is not possible to call 'eat' on a COW instance with a parameter of type FOOD.
+* In the class interface the 'variant' is removed. Indeed, it is not possible to call 'eat' on an entity of type COW with a parameter of type FOOD.
 <e>
@@ Line 107: / Line 107: @@
 feature -- Access
 	last: GRASS
 end

@@ Line 364: / Line 364: @@
 With a right abstraction and a smart use of variant typing for generics, it is possible to obtain a greater flexibility keeping a fully aivailable interface.
-=== Limit change ===
+=== Limit changes ===
 To limit code change and to increase typing consistency, we can change the semantic of 'variant'.

@@ Line 363: / Line 363: @@
 ==== Sub-conclusion ====
 With a right abstraction and a smart use of variant typing for generics, it is possible to obtain a greater flexibility keeping a fully aivailable interface.
 === Export status restrictions ===

@@ Line 319: / Line 319: @@
 To obtain the genric covariance behavior it is necessary to have:
 * V_ITERATOR must have a covariant generic.
-* TUPLE should be a read-only interface (MUTABLE_TUPLE would be the current TUPLE class). Therefore TUPLE could be conformed to V_SEQUENCE and MUTABLE_TUPLE conformed to V_ARRAY.
+* TUPLE should be a read-only interface (V_MUTABLE_TUPLE would be the current TUPLE class). Therefore TUPLE could be conformed to V_SEQUENCE and V_MUTABLE_TUPLE conformed to V_ARRAY. Note that only the readonly interface could be in the Eiffel Standard.
 In V_CONTAINER class only two features should use the variant typing: