From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id EB92DBB81 for ; Sat, 25 Feb 2006 12:44:36 +0100 (CET) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id k1PBiaaE030448 for ; Sat, 25 Feb 2006 12:44:36 +0100 Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id MAA18622 for ; Sat, 25 Feb 2006 12:44:35 +0100 (MET) Received: from kurims.kurims.kyoto-u.ac.jp (kurims.kurims.kyoto-u.ac.jp [130.54.16.1]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id k1PBiWii011401 for ; Sat, 25 Feb 2006 12:44:34 +0100 Received: from localhost (mikan [130.54.16.202]) by kurims.kurims.kyoto-u.ac.jp (8.13.1/8.13.1) with ESMTP id k1PBiU2j025799; Sat, 25 Feb 2006 20:44:31 +0900 (JST) Date: Sat, 25 Feb 2006 20:44:22 +0900 (JST) Message-Id: <20060225.204422.95892422.garrigue@math.nagoya-u.ac.jp> To: sejourne@limsi.fr, sejourne_kevin@yahoo.fr Cc: caml-list@inria.fr Subject: Re: [Caml-list] multiple inheritance, bug or feature ? From: Jacques Garrigue In-Reply-To: <440038EC.5060302@yahoo.fr> References: <440038EC.5060302@yahoo.fr> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce with ID 44004324.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at concorde with ID 44004320.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 bug:01 bug:01 overriding:01 redefining:01 overriding:01 a's:01 intentional:01 wrote:01 inherit:01 inherit:01 behaviour:01 behaviour:01 jacques:01 jacques:01 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.3 From: sejourne_kevin > class c = > object (self) > inherit a as aa > inherit a as bb > inherit b as cc > > method set_x_a x = aa#set x > method set_x_a' x = bb#set x > method set_y x = cc#set x > end > ;; > > Warning M: the following methods are overriden by the inherited class: set > Warning V: this definition of an instance variable x hides a previously > defined instance variable of the same name. > > Warning M: the following methods are overriden by the inherited class: > set [...] > When I wrote this program I expect this behavior but > according to the warnings M the result should be 3. If methods are > overriden, the same instance variable should be change (according to the > type of class c too). If the variable isn't change the method are not > overriden. So because methods are not overriden, I think there is a bug > in the warning system. The warning V look also suspicious. The warnings are correct, but they may be hard to follow. The point here is that when you call a method through "super" (i.e. the name after "as"), you are calling the original code, so no overriding occurs. So you have a warning about #set in c, but it is irrelevant to the use of aa#set or bb#set. Moreover, the current behaviour is that redefining a variable with the same name creates an independent variable. As a result set_x_a and set_x_a' access different variables. Note the distinction in the warnings: methods are overriden (the behaviour of self#set changes in previously defined methods), while variables are just hidden (newly defined method will only see the last defined variable, but old methods still see the original one.) We are actually discussing possibly changing the behaviour of variables, to have overriding rather than hiding, like for methods. As a result set_x_a and set_x_a' would become identical, except if v was made private by removing it from a's interface. If you have an opinion on which is more natural, I would be interested. I'm also wondering whether this is really necessary to have a warning for overriding through inheritance. If overriding was intentional, then the warning is pointless. Do you see situations where one could end up doing this unintentionally? Jacques Garrigue