Clemahieu at 17:05, 6 May 2008

2008-05-06T17:05:59Z

Clemahieu at 17:04, 6 May 2008

2008-05-06T17:04:40Z

New page

Do any of these methods cover covariance only through non-conforming inheritance? I think B. Schoeller touched on non-conforming inheritance at http://www.fams.de/text/type-safe-eiffel.html

If it were restricted to non-conforming inheritance it would obviously get rid of the export restriction problems.

Combining nc-inheritance and rechecking would allow even more than covariant redefinition, you could redefine an anchored type to any other type as long as the class text in the subclass was valid. This would essentially be equating redefinition in non-conforming inheritance to a textural insertion in subclasses.

<e>
class A
feature
b: INTEGER
double: like b is
do
result := b + b
end
end
</e>

<e>
--This could be a valid redefinition of A.b even though REAL does not conform to INTEGER since {REAL}b + {REAL}b is as valid as {INTEGER}b + {INTEGER}b
class C
inherit{NONE}
A
redefine
b
end
feature
b: REAL
</e>

It doesn't solve the generic case, however.

← Older revision		Revision as of 17:05, 6 May 2008
Line 1:		Line 1:
−	Do any of these methods cover covariance only through non-conforming inheritance? I think B. Schoeller touched on non-conforming inheritance at http://www.fams.de/text/type-safe-eiffel.html	+	Do any of these methods cover covariance only through non-conforming inheritance? I think B. Schoeller touched on non-conforming inheritance at http://www.fams.de/text/type-safe-eiffel.html and others, I've read so many existing suggestions I can't remember where I found them.

	If it were restricted to non-conforming inheritance it would obviously get rid of the export restriction problems.		If it were restricted to non-conforming inheritance it would obviously get rid of the export restriction problems.

Talk:Comparison of catcall solutions - Revision history

Clemahieu at 17:05, 6 May 2008

Clemahieu at 17:04, 6 May 2008