From: skaller <skaller@users.sourceforge.net>
To: brogoff <brogoff@speakeasy.net>
Cc: Brian Hurt <bhurt@spnz.org>,
Erik de Castro Lopo <ocaml-erikd@mega-nerd.com>,
caml-list <caml-list@inria.fr>
Subject: Re: [Caml-list] Programming with modules
Date: 21 Aug 2004 11:28:48 +1000 [thread overview]
Message-ID: <1093051727.29139.1503.camel@pelican.wigram> (raw)
In-Reply-To: <Pine.LNX.4.58.0408200914581.7889@shell2.speakeasy.net>
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
next prev parent reply other threads:[~2004-08-21 1:29 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-08-20 11:28 Erik de Castro Lopo
2004-08-20 11:45 ` Richard Jones
2004-08-20 11:59 ` Benjamin Geer
2004-08-20 11:59 ` Erik de Castro Lopo
2004-08-20 12:09 ` Richard Jones
2004-08-27 16:29 ` Richard Jones
2004-08-20 14:47 ` Brian Hurt
2004-08-20 16:56 ` brogoff
2004-08-21 1:28 ` skaller [this message]
2004-08-21 1:57 ` [Caml-list] Programming with classes Jean-Baptiste Rouquier
2004-08-21 2:44 ` skaller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1093051727.29139.1503.camel@pelican.wigram \
--to=skaller@users.sourceforge.net \
--cc=bhurt@spnz.org \
--cc=brogoff@speakeasy.net \
--cc=caml-list@inria.fr \
--cc=ocaml-erikd@mega-nerd.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox