Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[Caml-list] Recovering masked methods
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2002-07-16 (01:15)
From: Jacques Garrigue <garrigue@k...>
Subject: Re: [Caml-list] Recovering masked methods
From: Alessandro Baretta <>

> I have code similar to the following
> class a =
> object (self)
>    method m = 1
>    method n = "Hello!"
> end
> class b =
> object (self)
>    inherit a as super_a
>    method m = 2
> end
> Now I would like to define a third class, inheriting from b. 
>   I need this class to be able to access the definition of 
> method m from class a, otherwise I would have to use "copy & 
> paste", which is contrary to my programmer's ethics.

You don't need to be too ethical about that.
What's so great about strong typing, is that it makes copy-paste work!

And you can always write

let a_m = 1
class a = ... method m = a_m ..

This way you can still share the code (but you need to pass private
methods by hand).

If you want to stay indide the object, you can also save the old
method to a private one:

class b = ... method private a_m = super_a#m ...

> Ideally, I would like to write
> class c =
> object (self)
>    inherit b as super_b
>    method m =
>      (* some_stuff *)
>      super_b # super_a # m
> end
> Presently, this is not allowed. Is there any specific reason 
> for this? Could such a feature be implemented in the future?

OK, you want something like C++'s qualified calls?
There's no project to do that. Methods do not exist independently of
their class.
Another approach would be to provide views, as described by Jerome
Vouillon. That is, an object could keep some extra sets of methods in
an abstract way. But there's not project to implement that either.

Yet, it's not even clear such an ancestor call would make sense in
Could you give some more compelling example requiring such a feature?

To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list: