Re: [Caml-list] a design problem requiring downcasting? (long)

[Alessandro Baretta <alex@baretta.com>]

Michael Vanier wrote:
> I've run into a design problem that I think requires downcasting, and I
> wanted to see if anyone on the list has any ideas about an alternative
> approach, since AFAIK downcasting is impossible in the current ocaml object
> system (at least without nasty Obj.magic hacks).  I'll try to simplify the
> problem as much as possible, but this is still pretty long.
> <long explanation follows>
> 

Scratch... scratch... Hmmm...

I'm not really sure why you would want to use downcasts in 
your problem. I have been taught, as a general rule, that a 
downcast is (usually) a bug in the design and often also a 
bug in the implementation.

Downcasting in O'Caml is only useful when you have classes 
with *different* class types but sharing some common 
ancestor. Then you can keep a reference to the an object of 
the ancestor class and downcast it selectively to recover 
the methods added by inheriting classes. But, then again, if 
your design requires to keep a reference to a generic 
object, you are explicitly throwing out type information: in 
O'Caml upcasts are explicit, so you know *exactly* where you 
are throwing away type information. If you throw out type 
information and subsequently need a downcast to recover it, 
then you are probably working with a wrong abstraction 
somewhere in your analysis.

If I were you, I'd consider using a virtual base class as a 
common ancestor. Such a class would have to define all the 
public methods that might be called on any object. If a 
given method is truly meaningless within a specific class, 
you can always define it as raising a Meaningless_method 
exception, or something similar. But then you'd better make 
sure that your algorithm is correct, or it will die 
miserably with uncaught exceptions.

This is very much like downcasting, but it aids you in 
figuring out exactly what methods are creating the trouble. 
In my last project, I noticed that most typing problems with 
  classes were due to refinements of a base class being 
unified with their ancestor where this was not meaningful. 
It turned out that I could always solve this typing problem 
by isolating newly created objects of the inheriting 
classes, calling what additional methods the iheriting class 
defined in the appropriate order, and upcasting to the base 
class. The new object, thus initialized, could then be 
correctly type-restricted, without ever needing to recover 
the type information thrown away.

This strategy might not necessarily be appicable to your 
case, but I consider it, at least. It might save you a lot 
of hell. Remember: "If God wanted us to downcast, he would 
have given us RTTI."

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