Multiple constraints - Revision history

Conaclos: Syntax update

2013-05-08T19:52:47Z

Syntax update

Seilerm: /* Using whats there */

2007-11-06T22:03:45Z

‎Using whats there

Seilerm: /* Using whats there */

2007-11-06T22:03:34Z

‎Using whats there

Seilerm at 01:15, 28 March 2007

2007-03-28T01:15:04Z

Seilerm: /* Select */

2007-03-28T00:24:26Z

‎Select

Seilerm at 00:10, 28 March 2007

2007-03-28T00:10:42Z

Seilerm: /* Abstract creation */

2007-03-27T23:52:05Z

‎Abstract creation

Seilerm at 23:12, 27 March 2007

2007-03-27T23:12:09Z

Seilerm: /* Recursion issues */

2007-02-26T20:18:08Z

‎Recursion issues

Seilerm at 23:30, 20 February 2007

2007-02-20T23:30:40Z

@@ Line 37: / Line 37: @@
     g: G
-    example is
+    example
        do
-          g.f      -- qualified feature call
+          g.f	-- qualified feature call
        end
@@ Line 85: / Line 85: @@
     g: G
-    example is
+    example
        do
           g.f_b   -- qualified feature call with static type B
@@ Line 97: / Line 97: @@
 '''Using a local variable:'''
 <code>[eiffel,N]
-    example is
+    example
        local
           b: B
@@ Line 110: / Line 110: @@
 '''Using the object test:'''
 <e>
-    example is
+    example
        do
-          check {bg: B | g } end
+          check attached {B} g as bg then
-         bg.f  -- qualified feature call with static type B
+            bg.f  -- qualified feature call with static type B
        end
 </e>

@@ Line 253: / Line 253: @@
 For example one cannot introduce a class COMPARABLE_NUMERIC and then use it as a constraint.
-=== Using whats there ===
+=== Using what's there ===
 Issues which arise in the context of multi constraint formal generics are in many ways similar to the ones which have already been solved for multiple inheritance:

@@ Line 258: / Line 258: @@
 * Inheritance cycles are not valid
-* Select clauses are necessary to select a particular version of feature
+* Select clauses are necessary to select a particular version of a feature
 * Rename clauses are there to resolve name clashes

@@ Line 245: / Line 245: @@
 end
 </e>
-===Recursion issues===
+== A second look on multi constraints ==
 As we've already seen in the section about renaming-issues recursive formals can add quite a lot of complexity to the language.
@@ Line 257: / Line 273: @@
 One can however define certain things more general and maybe mathematically more consistent. But as constraints are to a formal, what inheritance is to a class, it seems also consistent to disallow cycles for formals as well. As a cycle in the inheritance hierarchy is indeed invalid.
-== Select clause ==
+=== Introduce a select clause with new semantics ===
 According to the standard only the ''rename clause'' can be used. The ''select'' and the ''redefine'' clause cannot be used.
 <e>
@@ Line 275: / Line 291: @@
 If the programmer wants to access the versions of is_equal from X and Y he simply renames at least one of them to a different name.

← Older revision		Revision as of 00:24, 28 March 2007
Line 257:		Line 257:
	One can however define certain things more general and maybe mathematically more consistent. But as constraints are to a formal, what inheritance is to a class, it seems also consistent to disallow cycles for formals as well. As a cycle in the inheritance hierarchy is indeed invalid.		One can however define certain things more general and maybe mathematically more consistent. But as constraints are to a formal, what inheritance is to a class, it seems also consistent to disallow cycles for formals as well. As a cycle in the inheritance hierarchy is indeed invalid.

−	== Select ==	+	== Select clause ==
		+	According to the standard only the ''rename clause'' can be used. The ''select'' and the ''redefine'' clause cannot be used.
		+	<e>
		+	class MULTI [G -> {X select is_equal end,
		+	Y select default_create end} create default_create end]
		+
		+	feature
		+	g: G
		+
		+	some_feature
		+	do
		+	create g
		+	if g.is_equal (g) then
		+	end
		+	end
		+	</e>
		+
		+	If the programmer wants to access the versions of is_equal from X and Y he simply renames at least one of them to a different name.

← Older revision		Revision as of 00:10, 28 March 2007
Line 256:		Line 256:
	The conclusion is, that recursion has no practical benefit for the developer.		The conclusion is, that recursion has no practical benefit for the developer.
	One can however define certain things more general and maybe mathematically more consistent. But as constraints are to a formal, what inheritance is to a class, it seems also consistent to disallow cycles for formals as well. As a cycle in the inheritance hierarchy is indeed invalid.		One can however define certain things more general and maybe mathematically more consistent. But as constraints are to a formal, what inheritance is to a class, it seems also consistent to disallow cycles for formals as well. As a cycle in the inheritance hierarchy is indeed invalid.
		+
		+	== Select ==

← Older revision		Revision as of 23:52, 27 March 2007
Line 130:		Line 130:

	==Abstract creation==		==Abstract creation==
		+	It is not perfectly clear by reading the standard what the semantics of
		+	<e>
		+	create g
		+	</e>
		+	Where the type of ''g'' is a multi-constraint formal.
		+
		+	===By name===
		+	Require a feature with name ''default_create'' in creation constraint clause and use that for the creation. But remember the routine id and the type as an actual generic derivation may use different renaming.
		+
		+	* New semantic
		+	* Programmer can always use an instruction of the form <e>create g</e> as soon as he as a creation constraint with the name ''default_create''.
		+
		+	===By version===
		+	Require exactly one version of ''default_create'' from ''ANY'' in creation constraint clause to make a call like <e>create g</e> valid.
		+
		+	* No new semantic
		+	* Programmer cannot always use an instruction of the form <e>create g</e>
		+
		+	The following code illustrates a case where it is not possible to use <e>create g</e>.
		+	<e>
		+	class MULTI [G -> {X rename default_create as dc_x,
		+	Y rename default_create as dc_y end} create dc_x, dc_y end]
		+	feature
		+	g: G
		+
		+	some_feature
		+	-- Some feature
		+	do
		+	create g.dc_x -- 1
		+	create g.dc_y -- 2
		+	create g -- 3
		+	end
		+	end
		+	</e>
		+	* 1 and 2: The creation of ''g'' is ok as we have an explicit invocation of the creation feature.
		+	* 3: The abstract creation is not ok as ''dc_x'' and ''dc_y'' are both versions of ''default_create'' from ''ANY''.

	==Formal generic type parameters in constraints==		==Formal generic type parameters in constraints==

← Older revision		Revision as of 23:12, 27 March 2007
Line 128:		Line 128:

	The renaming clause for multi-constraint types could be removed and name clashes could be regarded as ambiguous cases too. The user resolves it as shown above by choosing a static type explicitly over locals and object tests only.		The renaming clause for multi-constraint types could be removed and name clashes could be regarded as ambiguous cases too. The user resolves it as shown above by choosing a static type explicitly over locals and object tests only.
		+
		+	==Abstract creation==

	==Formal generic type parameters in constraints==		==Formal generic type parameters in constraints==

@@ Line 208: / Line 208: @@
 </e>
 ===Recursion issues===
-As we've already seen in the section about renaming issues recursive formals can add quite a lot of complexity to the language.
+As we've already seen in the section about renaming-issues recursive formals can add quite a lot of complexity to the language.
 Let's again have a look at this simple example:

@@ Line 216: / Line 216: @@
 </e>
 A valid generic derivation for this example has the property, that both formals have to be '''exactly the same type'''. Otherwise it's impossible to meet the constraints.
-The conclusion is, that recursion has no practical for the developer.
+The conclusion is, that recursion has no practical benefit for the developer.
 One can however define certain things more general and maybe mathematically more consistent. But as constraints are to a formal, what inheritance is to a class, it seems also consistent to disallow cycles for formals as well. As a cycle in the inheritance hierarchy is indeed invalid.