Comparison of catcall solutions - Revision history

Conaclos: Export status restrictions not adressed for Default and explicit variance

2013-08-29T14:35:50Z

Export status restrictions not adressed for Default and explicit variance

Conaclos: Correction for Default and explicit variance

2013-08-29T14:31:27Z

Correction for Default and explicit variance

Conaclos: Precision for agent conformance

2013-05-10T09:51:30Z

Precision for agent conformance

Conaclos: Add precision

2013-05-09T22:26:17Z

Add precision

Conaclos: Add a comparison

2013-05-08T16:57:44Z

Add a comparison

Conaclos: adding Default and explicit variance as general solution

2013-05-08T16:39:14Z

adding Default and explicit variance as general solution

Juliant: /* Overview of general solutions */

2007-07-06T16:34:03Z

‎Overview of general solutions

Juliant: /* Overview of general solutions */

2007-07-06T02:55:42Z

‎Overview of general solutions

Juliant: /* Overview of general solutions */

2007-07-06T02:55:29Z

‎Overview of general solutions

Juliant: /* Solutions for generics */

2007-06-24T19:09:06Z

‎Solutions for generics

@@ Line 221: / Line 221: @@
 | {{Green|Allowed}}
 | {{Green|Allowed}}
-| {{Red|Not allowed}}
+| Not addressed
 |-

@@ Line 237: / Line 237: @@
 | {{Orange|Limited}}<br/>{{Green|Safe}}
 | {{Red|As it is now}}
-| {{Green|Fully supported}}<br/>{{Green|Safe}} Class change needed for contravariant conformance
+| {{Green|Fully supported}}<br/>{{Green|Safe}} - Class change needed for contravariant conformance
 |-
@@ Line 261: / Line 261: @@
 | {{Orange|Medium}}: Need to know cat features for object tests
 | {{Green|Small}}: As it is now
-| {{Green|Small}}: Consider variance in object test for variant typing
+| {{Green|Small}}: As it is now
 |-

@@ Line 237: / Line 237: @@
 | {{Orange|Limited}}<br/>{{Green|Safe}}
 | {{Red|As it is now}}
-| {{Green|Fully supported}}<br/>{{Green|Safe}}
+| {{Green|Fully supported}}<br/>{{Green|Safe}} Class change needed for contravariant conformance
 |-

@@ Line 293: / Line 293: @@
 | {{Orange|Possible}}: Can propose forget/keep clauses
 | {{Green|Not needed}}
-| {{Orange|Possible}}: Can propose variant mark
+| {{Orange|Possible}}: Can propose variant mark for unsafe redefinition and for automatic generic variance detection.
-−
 |}

@@ Line 185: / Line 185: @@
 |- style="visibility: hidden"
-| style="width:25%" |
+| style="width:20%" |
-| style="width:25%" |
+| style="width:20%" |
-| style="width:25%" |
+| style="width:20%" |
-| style="width:25%" |
+| style="width:20%" |
 |-
@@ Line 196: / Line 197: @@
 ! [[Forget / keep]]
 ! Dynamic typeset algorithm
 |-
@@ Line 202: / Line 204: @@
 | {{Green|No}}
 | {{Red|Big}}: forget/keep clauses per type
 | {{Green|No}}
@@ Line 208: / Line 211: @@
 ! Covariance on non-generic types
 | {{Red|Not allowed}}
 | {{Green|Allowed}}
 | {{Green|Allowed}}
@@ Line 217: / Line 221: @@
 | {{Green|Allowed}}
 | {{Green|Allowed}}
 |-
@@ Line 224: / Line 229: @@
 | {{Orange|Limited}}: Conformance restricted (''keep all'' as default)<br/>{{Orange|Limited}}: Use restricted (''forget all'' as default)
 | {{Green|As it is now}}
 |-
@@ Line 231: / Line 237: @@
 | {{Orange|Limited}}<br/>{{Green|Safe}}
 | {{Red|As it is now}}
 |-
@@ Line 238: / Line 245: @@
 | {{Red|Not supported}}
 | {{Red|Not supported}}
 |-
@@ Line 245: / Line 253: @@
 | {{Orange|Medium}}: Check of feature call for all descendants; Conformance check on forget/keep clauses
 | {{Red|Big}}: Iterative abstract system execution
 |-
@@ Line 252: / Line 261: @@
 | {{Orange|Medium}}: Need to know cat features for object tests
 | {{Green|Small}}: As it is now
 |-
@@ Line 259: / Line 269: @@
 | {{Red|Yes}}: use of ''forget all'' depends on system
 | {{Red|Yes}}
 |-
@@ Line 266: / Line 277: @@
 | {{Red|No}}
 | {{Red|No}}
 |-
@@ Line 273: / Line 285: @@
 | {{Orange|Limited}}
 | {{Green|Full}}
 |-
@@ Line 280: / Line 293: @@
 | {{Orange|Possible}}: Can propose forget/keep clauses
 | {{Green|Not needed}}
 |}

← Older revision		Revision as of 16:39, 8 May 2013
Line 93:		Line 93:

	Read-write types are a solution which can model interval types and usage-site variance. It splits a type into a ''read'' type and a ''write'' type. The read type defines the applicable features and the write type the signature to check for valid arguments.		Read-write types are a solution which can model interval types and usage-site variance. It splits a type into a ''read'' type and a ''write'' type. The read type defines the applicable features and the write type the signature to check for valid arguments.
		+
		+	=== [[Default and explicit variance]] ===
		+	Default and explicit variance is inspired of usage-site variance and detachable proposition.
		+	The proposition add no new keyword.

	== Overview of solutions for non-generics ==		== Overview of solutions for non-generics ==

← Older revision		Revision as of 16:34, 6 July 2007
Line 89:		Line 89:

	Interval types allow to define each type as an interval with a lower and upper type as boundary. This limits the dynamic type set and thus restricts the number of features which need to be checked for system-validity. In addition to this, it defines rules which handle the case of features with formal arguments.		Interval types allow to define each type as an interval with a lower and upper type as boundary. This limits the dynamic type set and thus restricts the number of features which need to be checked for system-validity. In addition to this, it defines rules which handle the case of features with formal arguments.
		+
		+	=== [[Read-write types]] ===
		+
		+	Read-write types are a solution which can model interval types and usage-site variance. It splits a type into a ''read'' type and a ''write'' type. The read type defines the applicable features and the write type the signature to check for valid arguments.

	== Overview of solutions for non-generics ==		== Overview of solutions for non-generics ==

@@ Line 86: / Line 86: @@
 The dynamic typeset algorithm does not change any semantics of the types or the conformance as it is in Eiffel already, it only does an abstract execution of the system to limit the possibilities per feature call which have to be checked if they are safe.
-=== [[Interval types]]] ===
+=== [[Interval types]] ===
 Interval types allow to define each type as an interval with a lower and upper type as boundary. This limits the dynamic type set and thus restricts the number of features which need to be checked for system-validity. In addition to this, it defines rules which handle the case of features with formal arguments.

← Older revision		Revision as of 02:55, 6 July 2007
Line 85:		Line 85:

	The dynamic typeset algorithm does not change any semantics of the types or the conformance as it is in Eiffel already, it only does an abstract execution of the system to limit the possibilities per feature call which have to be checked if they are safe.		The dynamic typeset algorithm does not change any semantics of the types or the conformance as it is in Eiffel already, it only does an abstract execution of the system to limit the possibilities per feature call which have to be checked if they are safe.
		+
		+	=== [[Interval types]]] ===
		+
		+	Interval types allow to define each type as an interval with a lower and upper type as boundary. This limits the dynamic type set and thus restricts the number of features which need to be checked for system-validity. In addition to this, it defines rules which handle the case of features with formal arguments.
		+
	== Overview of solutions for non-generics ==		== Overview of solutions for non-generics ==

@@ Line 408: / Line 408: @@
 ! Agents
 | {{Green|Fully supported}}<br/>{{Green|Safe}}
-| {{Orange|Fully supported}}<br/>{{Green|Safe}}: If tuples can be specified covariantly
+| {{Green|Fully supported}}: If tuples can be specified covariantly<br/>{{Green|Safe}}
 | {{Green|Fully supported}}<br/>{{Green|Safe}}