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

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