* Re: subtyping and inheritance - correction
[not found] <no.id>
@ 1999-01-16 18:58 ` Markus Mottl
0 siblings, 0 replies; only message in thread
From: Markus Mottl @ 1999-01-16 18:58 UTC (permalink / raw)
To: mottl; +Cc: OCAML
Hello,
in my last mail, I proposed the following rule for coercion of objects to
ancestors in the inheritance hierarchie:
If an object that has inherited from another class is coerced to this
class, then the definition *and* the type of all methods should be
taken from this ancestor. Because the object *must* have all the data
defined in its ancestor (it has inherited all of it), the use of the
ancestor's methods should not lead to any inconsistencies.
This is not correct! In this case it would be impossible to make use of
virtual functions, which is, of course, not what I intend.
The correct rule should be:
If an object that has inherited from another class is coerced to this
class, then the definition of all methods
*** that mismatch in type ***
should be taken from this ancestor...
My first proposition was a bit too general... ;-)
There are two cases in which this rule would be useful:
* Since the 'self-type is unique for every class, it would be impossible
without this rule to coerce *any* descendant to *any* of its ancestors
if the 'self-type has been used in them. This, although all methods
of the ancestors could be safely applied to the object.
* It might also be in the interest of the programmer to "manually" use
new types in a method that carries a name already found in ancestors.
If a method is called with parameters of types unknown to the object,
the compiler could try to find a matching definition in ancestors.
The first match found on traversal from bottom to the top would then be
taken.
This could actually give a polymorphic touch to the OO-part:
considering the example presented in the last mail, it would not even
be necessary then to explicitely use coercion. E.g. in
a_terminal#compare a_symbol
the compiler could see that the "compare"-method in "terminal" does
not fit to parameters of type "symbol". It would look up definitions in
ancestors and see that there is a matching method in ancestor "symbol".
One of the downsides of this might be that the programmer could more
easily make mistakes - he might believe that the "compare"-method is
taken from "terminal", which is not the case. Still, the program would
type check correctly but behave different to the expectations of the
programmer...
I don't know whether this problem is severe. Because class type (in
general) is not explicitely stated, the programmer would have to verify
anyway, from which class the method is taken.
Strict separation of semantic properties (class types / interfaces) and
syntactic relations (inheritance) of classes probably provides for higher
security in programming and appears more elegant from a formal point of
view. But sometimes it doesn't seem to reflect the way the programmer
(only I??) thinks.
Since I am not an expert in class/type systems, it might well be possible
that my propositions are foolish. I have just tried to describe what
would appear natural in the use of objects to me... ;-)
Best regards,
Markus Mottl
--
Markus Mottl, mottl@miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl
^ permalink raw reply [flat|nested] only message in thread