Difference between revisions of "Talk:Comparison of catcall solutions"
m |
|||
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. |
Latest revision as of 08:05, 6 May 2008
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.
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.
class A feature b: INTEGER double: like b is do result := b + b end end
--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
It doesn't solve the generic case, however.