From: Markus Mottl <mottl@miss.wu-wien.ac.at>
To: mottl@miss.wu-wien.ac.at.pc7.nis (mottl)
Cc: caml-list@inria.fr (OCAML)
Subject: Re: subtyping and inheritance - correction
Date: Sat, 16 Jan 1999 19:58:55 +0100 (MET) [thread overview]
Message-ID: <199901161858.TAA11584@miss.wu-wien.ac.at> (raw)
In-Reply-To: <no.id> from "mottl" at Jan 15, 99 06:37:26 pm
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
parent reply other threads:[~1999-01-18 11:05 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <no.id>]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=199901161858.TAA11584@miss.wu-wien.ac.at \
--to=mottl@miss.wu-wien.ac.at \
--cc=caml-list@inria.fr \
--cc=mottl@miss.wu-wien.ac.at.pc7.nis \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).