caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Jacques Garrigue <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 ?
Date: Sat, 25 Feb 2006 20:44:22 +0900 (JST)	[thread overview]
Message-ID: <20060225.204422.95892422.garrigue@math.nagoya-u.ac.jp> (raw)
In-Reply-To: <440038EC.5060302@yahoo.fr>

From: sejourne_kevin <sejourne_kevin@yahoo.fr>

> 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


  reply	other threads:[~2006-02-25 11:44 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-25 11:01 sejourne_kevin
2006-02-25 11:44 ` Jacques Garrigue [this message]
2006-02-25 11:55   ` [Caml-list] " Oliver Bandel
2006-02-25 11:48 ` Oliver Bandel
2006-02-25 12:09   ` sejourne_kevin
2006-02-25 12:16     ` Oliver Bandel
2006-02-25 12:33       ` Oliver Bandel

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=20060225.204422.95892422.garrigue@math.nagoya-u.ac.jp \
    --to=garrigue@math.nagoya-u.ac.jp \
    --cc=caml-list@inria.fr \
    --cc=sejourne@limsi.fr \
    --cc=sejourne_kevin@yahoo.fr \
    /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).