Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] Programming with modules
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: skaller <skaller@u...>
Subject: Re: [Caml-list] Programming with modules
On Sat, 2004-08-21 at 02:56, brogoff wrote:

> There are a few cases where you really do want to support cross module
> dependencies, but this seems to be hard to do in a satifactory way. The
> issue is made worse IMO by the addition of OO, since class hierarchies,
> at least the ones I've used, tend to have more cyclic dependencies.

Actually, I have not found that. If you follow
the following general technique, the problem
is eliminated, except from constructors.

First, you have to make a distinct class type for
each kind of object. These are all declared together
in a single mli file, recursively: I'll call
these the abstract class types.

Next, define your classes in an arbitrary order.
It is important that all variables including
arguments to methods use the abstract class types
for typing -- NEVER use the concrete class types
of the concrete classes you're defining.

This obviously ensures that the concrete classes are
independent of each other: in particular, the precise
concrete representation can be changed as you see fit,
provided of course it conforms to its abstract type.

There is a further step: constructors. Never export
class constructors. They must be wrapped in a normal
Ocaml function which returns an abstract class type.

Constructors are the *only* difficult thing to get
right -- all the rest of this mechanism is obvious
and should be done by rote. The reason constructors
are tricky is that sometimes a concrete class must be
constructed using other concrete classes.

In general, if you have a problem ordering the
concrete classes and constructors acyclically --
it is a strong indication your design is wrong.
OO simply isn't a general paradigm, its form
of abstraction is incapable of solving most
problems involving 'relationships' since relationships
are typically covariant.

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



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