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