From: Markus Mottl <mottl@miss.wu-wien.ac.at>
Message-Id: <199901250008.BAA29432@miss.wu-wien.ac.at>
Subject: Re: subtyping and inheritance
To: tews@irritatie.cs.kun.nl (Hendrik Tews)
Date: Mon, 25 Jan 1999 01:08:30 +0100 (MET)
In-Reply-To: <199901201150.MAA09911@irritatie.cs.kun.nl> from "Hendrik Tews" at Jan 20, 99 12:50:21 pm
Hello,
> This is true. But what you really need to solve your problem is a
> feature called sometimes "(covariant) specialization of code".
> Ocaml does not have this feature. Therefore you can not hope for
> a solution which is typesafe and supports code reuse. Ocaml does
> provide the feature "contravariant subtyping", which gives you a
> save subtype relation. There is nice paper of Guiseppe Castagna
> "Covariance and Contravariance: Conflict without a Cause" [1]
> which discusses those features and their relation.
>
> This paper and the references therein contain also proposals how
> to integrate specialization of code into a record based object
> oriented language. Is their any hope, that ocaml adopts this (or
> any other) solution in the future, such that Markus can implement
> comparison of terminals and symbols in a clean way?
> [1] G. Castagna. Covariance and contravariance: conflict without
> a cause. ACM Transactions on Programming Languages and Systems
> 17(3):431-447, March 1995. Also available at
> http://www.ens.fr/~castagna/pub.html.
I have taken a close look on the paper now. As it seems, it exactly
addresses the problem I (and probably many others) have. Quotes with
[remarks]:
... Despite its unsoundness, covariant specialization has its tenacious
defenders, and not without cause. [snip] The contravariant rule,
besides being less intuitive than the covariant one, is the source of
many problems. The most surprising one appears with binary methods
and can be exemplefied as follows. [snip details of the problem I
actually have]. This is quite unintuitive [yes, I think so, too]
[snip]. Furthermore, experience with O2 (which is the third most
sold object-oriented database management system in the world) shows,
that the unsoundness of the type-checker has not caused many problems
in practice.
So far it seems that things would be unsafe with covariance. But now,
Castagna answers my (former) question, whether making "reappear" methods
from ancestors would be safe: it is...
The paper looked difficult at first, but turned out to be surprisingly
easy to read: Castagna makes the theorie very intuitively clear with his
examples of classes "2DPoint" and "3DPoint" and how methods are chosen
in the different models.
The record based method (as found in OCAML - the object (record)
determines, which method is selected, arguments are not considered)
can be obviously extended to support covariance.
Sylvain Boulmé pointed out that semantics could become difficult to
understand. I am not sure whether this would really turn out to be a
problem. Implementing a large project employing a deep class hierarchie
in both approaches could probably demonstrate, where their strengths
and weaknesses are. But at the moment, we don't have this choice...
> There was already a proposal how to solve the problem by Jerome
> Vouillon. Just for demonstration I append another solution, which
> uses a self implemented type case. It supports code reuse better,
> but loses type security by using the Obj module. Maybe one of the
> people who "understand the whole source code for the O'Caml
> compiler, runtime and libraries" and by that can use the Obj
> module, can comment on its use here.
[snip code]
Nice example code! I don't know what "Obj.magic" does internally,
but I believe it can do real black (= unintended) magic, too. Thus,
it is certainly not advisable to use it as a surrogate for the missing
feature of covariance. But Hendrik's intention is surely to demonstrate,
how objects could behave in such an environment...
Best regards,
Markus
-- Markus Mottl, mottl@miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl
This archive was generated by hypermail 2b29 : Sun Jan 02 2000 - 11:58:18 MET