Re: subtyping and inheritance - correction

Re: subtyping and inheritance - correction

[Markus Mottl]

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