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 (11:01)
From: Alessandro Baretta <alex@b...>
Subject: Re: [Caml-list] Recovering masked methods (with CamlP4?)
Johan Baltié wrote:
> I do not agree with you on the usefullness of this kind of stuff.
> Basic OO theory says that the inheritance relation can be seen as a "is a" operator.
> If your "is a" means "is a with some variants", for me your modelization is not
> good.
> You should have:
>  B' inherits A 
>  B inherits B'
>  small_b_variant inherits B'
> Like this code factorisation seems to be easy to do. 
> IMHO it's a good modelization constraint to forbid such stuff.

I strongly disagree. Inheritance, as pointed out previously 
by someone on this list (I can't remember whom), is a 
syntactic property of classes, whereas subtyping is a 
semantic property of instances. Just now I have received a 
post by John Prevost clarifying this.

In my code,
class a = object method m = ... end
Provides basic functionality common to all my inheritance 
hiearchy. Class a *also* defines the actual type of all my 
inheritance hieararchy, so I do not use subtyping at all; I 
use type *identity*. That's because I'm building a graph of 
objects of different classes, so all the objects in the 
graph need to have the same type. I only use inheritance 
because of code sharing. Now,
class b = object inherit a ... end
performs extensive personalizations to the functionality 
provided by class a, while always retaining the 
functionality of the parent, which is accessed by sending 
messages to super_a. Class var_b needs most of the 
functionality provided by b, with the sole exception of one 
method, which I call here m, which needs to be identical to 
the one defined in the root of the hierarchy. Hence, for the 
sake of code reuse, since var_b shares most of its code with 
b, it must inherit from b; however, for the sake of not 
having multiple copies of the same lines of code--a 
maintainance issue--I *also* need var_b to inherit, albeit 
indirectly, form a. This is my reason for requesting and 
"explicit inheritance hierarchy" construct. I think it 
should pose no semantic issues with the OO system of Caml. 
It should simply allow explicit scoping of inherited 
methods. Please, note that it is merely a bit of syntactic 
sugar. To think of it, it might even be implemented with CamlP4.

CamlP4 could perform the following code transformation:
class a =
   method m = <some stuff>

class a =
   private method __class_a__m = <some stuff>
   method m = self # __class_a__m


class var_b =
   inherit a as super_a through b as super_b
   method m = super_a # m


class var_b =
   inherit b as super_b
   method m = __class_a__m

Daniel, I'm no CamlP4 guru. Would this scheme work?


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