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:32)
From: Johan Baltié <johan.baltie@w...>
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"
> > 
> > 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.

Uhh ? I have missed something. Can you forward me this post privately ? I cannot
find it. It seems awful to me to hear that inheritance is "syntactic", because
it does mean (for me) that nothing happen at runtime.

> 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. 

You say "since var_b shares most of its code with b, it must inherit from b".
If you do not like my little B' class (I do not understand why), then say "b
share most of this code with var_b, it must inherit from var_b", with b a
specialization of var_b.

For me it's still modelization problem.


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