From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: weis Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id MAA00961 for caml-redistribution; Mon, 18 Jan 1999 12:05:25 +0100 (MET) Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id TAA17410 for ; Sat, 16 Jan 1999 19:58:58 +0100 (MET) Received: from miss.wu-wien.ac.at (miss.wu-wien.ac.at [137.208.107.17]) by nez-perce.inria.fr (8.8.7/8.8.7) with ESMTP id TAA03445 for ; Sat, 16 Jan 1999 19:58:56 +0100 (MET) Received: (from mottl@localhost) by miss.wu-wien.ac.at (8.9.0/8.9.0) id TAA11584; Sat, 16 Jan 1999 19:58:55 +0100 (MET) From: Markus Mottl Message-Id: <199901161858.TAA11584@miss.wu-wien.ac.at> Subject: Re: subtyping and inheritance - correction To: mottl@miss.wu-wien.ac.at.pc7.nis (mottl) Date: Sat, 16 Jan 1999 19:58:55 +0100 (MET) Cc: caml-list@inria.fr (OCAML) In-Reply-To: from "mottl" at Jan 15, 99 06:37:26 pm X-Mailer: ELM [version 2.4 PL21] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: weis 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