> John Prevost wrote:
> 
> > You've simply got the wrong ordering in your inheritance.  There's
> > absolutely no need for more functionality to support accessing "older"
> > methods in this case.  (I'd argue there's no need in any case.)  And
> > again, even if method m had to be different in var_b, it would be
> > better to use an inherited class which has the features common to b
> > and var_b.  In this case, that class is identical to b.
> > 
> > John.
> 
> Not a bad idea, actually. From a conceptual standpoint it 
> works. It did not occur to me go about coding that way 
> because my classes come in "related packages", and given 
> this conceptual grouping, it would sort of look funny to 
> implement what you suggested.
> ...
> Now that you make me think of it, all I need is an 
> intermediate class in my hierarchy, factoring all the the 
> common functionality with the exception of two methods: 
> let's say m and n. I'll then have a package inherit from the 
> common ancestor and redefine m, while the other package 
> redefines n. This intermediate layer will remove the need to 
> call a method in a farther ancestor.
> 
> Thank you for the suggestion.
> 
> Alex
 
I think I express myself very badly because it sounds like my little B' class....

*sigh* 
:,(



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