multiple inheritance, bug or feature ?

multiple inheritance, bug or feature ?

[sejourne_kevin]

Hello :


Consider the following sample :

class a =
object
   val mutable x = 0
   method set v = Printf.printf "%d\n" x;x <- v
end
;;
class a : object val mutable x : int method set : int -> unit end


class b =
object
   val mutable y = 0
   method set v = Printf.printf "%d\n" y;y <- v
end
;;

class b : object val mutable y : int method set : int -> unit end
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

class c :
   object
     val mutable x : int
     val mutable y : int
     method set : int -> unit
     method set_x_a : int -> unit
     method set_x_a' : int -> unit
     method set_y : int -> unit
   end

let d = new c;;
val d : c = <obj>

d#set_x_a 3;;
0
- : unit = ()

d#set_x_a' 2;;
0
- : unit = ()


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.




Kevin.

	

	
		
___________________________________________________________________________ 
Nouveau : téléphonez moins cher avec Yahoo! Messenger ! Découvez les tarifs exceptionnels pour appeler la France et l'international.
Téléchargez sur http://fr.messenger.yahoo.com

Re: [Caml-list] multiple inheritance, bug or feature ?

[Jacques Garrigue]

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

Re: [Caml-list] multiple inheritance, bug or feature ?

[Oliver Bandel]

On Sat, Feb 25, 2006 at 12:01:00PM +0100, sejourne_kevin wrote:
> Hello :
> 
> 
> Consider the following sample :
> 
> class a =
> object
>   val mutable x = 0
>   method set v = Printf.printf "%d\n" x;x <- v
> end
> ;;
[...]
 
> class c :
>   object
>     val mutable x : int
>     val mutable y : int
>     method set : int -> unit
>     method set_x_a : int -> unit
>     method set_x_a' : int -> unit
>     method set_y : int -> unit
>   end
> 
> let d = new c;;
> val d : c = <obj>
> 
> d#set_x_a 3;;
> 0
> - : unit = ()
> 
> d#set_x_a' 2;;
> 0
> - : unit = ()
> 
> 
> When I wrote this program I expect this behavior but
> according to the warnings M the result should be 3.

Why do you think the expected behaviour should be
printing the 3?

Your method prints the old value, not the new value.

=======================
# let o = new c;;
val o : c = <obj>
# o#set_x_a 10;;
0
- : unit = ()
# o#set_x_a 20;;
10
- : unit = ()
# o#set_x_a 30;;
20
- : unit = ()
# 
=======================


If you want to print the current value after update,
you should also write your code in the way it it does this.
So, you should write it in this way:

  method set v = x <- v; Printf.printf "%d\n" x


Ciao,
   Oliver

Re: [Caml-list] multiple inheritance, bug or feature ?

[Oliver Bandel]

On Sat, Feb 25, 2006 at 08:44:22PM +0900, Jacques Garrigue wrote:
[...]
> 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?


Every warning that a compiler can throw makes sense for someone
who might need this.
Is this warning possible to turn off? Then you could do it.
But I prefer as default have more warnings, not less.


Well, OO should help to have less copy&pasted code, but some things
might be done in this way.
A warning on the overridden methods IMHO make sense.

Ciao,
   Oliver

Re: [Caml-list] multiple inheritance, bug or feature ?

[sejourne_kevin]

Oliver Bandel a écrit :

>>When I wrote this program I expect this behavior but
>>according to the warnings M the result should be 3.
> 
> 
> Why do you think the expected behaviour should be
> printing the 3?
> 
> Your method prints the old value, not the new value.
> 
I know that. That is not the problem. The problem is that
there is two references on two differents values.
set_x_a' set_x_a are not using the same 'x'.

	

	
		
___________________________________________________________________________ 
Nouveau : téléphonez moins cher avec Yahoo! Messenger ! Découvez les tarifs exceptionnels pour appeler la France et l'international.
Téléchargez sur http://fr.messenger.yahoo.com

Re: [Caml-list] multiple inheritance, bug or feature ?

[Oliver Bandel]

On Sat, Feb 25, 2006 at 01:09:39PM +0100, sejourne_kevin wrote:
> Oliver Bandel a écrit :
> 
> >>When I wrote this program I expect this behavior but
> >>according to the warnings M the result should be 3.
> >
> >
> >Why do you think the expected behaviour should be
> >printing the 3?
> >
> >Your method prints the old value, not the new value.
> >
> I know that. That is not the problem. The problem is that
> there is two references on two differents values.
> set_x_a' set_x_a are not using the same 'x'.


Yes.

As you called one of your internal states "y", not "x"
I would expect the behaviour that your implementation
shows.

But I changes then in class b the "y" to "x" and it showed
the same behaviour.

Well, this is what I didn't expected...

and the error messages, on which I now looked in more detail,
well, are strange... (also in your case...)

?!

Ciao,
   Oliver

Re: [Caml-list] multiple inheritance, bug or feature ?

[Oliver Bandel]

On Sat, Feb 25, 2006 at 01:16:28PM +0100, Oliver Bandel wrote:
[...]
> 
> Yes.
> 
> As you called one of your internal states "y", not "x"
> I would expect the behaviour that your implementation
> shows.
> 
> But I changes then in class b the "y" to "x" and it showed
> the same behaviour.
> 
> Well, this is what I didn't expected...
> 
> and the error messages, on which I now looked in more detail,
> well, are strange... (also in your case...)
> 
> ?!


Oh, I see... by inheriting

class a twice....  well, sorry, I had completely overseen
that you inherit class "a" twice.... 

well.... ;-)

> 
> Ciao,
>    Oliver
> 
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs