> [sniped]
> 
> > And you can always write
> > 
> > let a_m = 1
> > class a = ... method m = a_m ..
> 
> This is not viable. The toy code I have shown here does not 
> provide any real functionality, but in the real application 
> you have to imagine the following situation:
> 
> class a =
> object (self)
>    method m = <some generally useful stuff
>    method m1 = <other generally useful stuff>
>    ...
>    method mn = <other generally useful stuff>
> end
> 
> class b =
> object (self)
>    inherit a as super_a
>    method m = <specific stuff>; super_a # m
>    method m1 = <specific stuff>; super_a # m1
>    ...
>    method mn = <specific stuff>; super_a # mn
> end
> 
> class small_variant_of_b =
> object (self)
>    inherit b as super_b
>    method m = super_b # super_a # m
> (* All the specific stuff in method m is not needed *)
> (* Yet, all other methods must be inherited from b  *)
> end
> 
> Without the above notation, I could only think of copying 
> the code of method m out of class a and pasting it into 
> class small_variant_of_b, but this makes maintainance a 
> mess. And I am working on a production class system. No 
> good. However, I did not consider the following idea, which 
> is not bad indeed. In the absence of the notation I 
> described above, or of an equivalent one, I'll do as you 
> propose here.

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.

> [resniped]

Ciao

Jo
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners