caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: skaller <skaller@users.sourceforge.net>
To: "chris.danx" <chris.danx@ntlworld.com>
Cc: Caml Mailing List <caml-list@inria.fr>
Subject: Re: [Caml-list] Restricting Method Overriding/Redefinition in Subclass
Date: 14 Aug 2004 17:38:57 +1000	[thread overview]
Message-ID: <1092469137.29139.564.camel@pelican.wigram> (raw)
In-Reply-To: <411D56EC.2070301@ntlworld.com>

On Sat, 2004-08-14 at 10:03, chris.danx wrote:

> Perhaps a radically different solution is best?  I chose an OO solution 
> so that new classes could be trivially added to the system.

There is another kind of solution you might investigate.

Instead of trying to unify all your data types using 
abstraction -- classes provide abstraction --
use summation instead.

A summation solution looks like:

type obj = [
  | `A of a 
  | `B of b * obj 
  | `C of c * obj * obj
]

using polymorphic variants. In order to 
'do something' with each object, including
children, you write a 'visitor' style function:

let rec iter x = match x with
  | `A  a -> do_a a
  | `B (b ,kid) -> do_b b; iter kid
  | `C (c, k1, k2) -> iter k1; do_c c; iter k2


When you need to add a new object type to this
system you have to add the method for handling
it, just as in the OO solution.

The difference is that the method doesn't go
in with the data lexically, but separately
in the visitor function. Ocaml will make sure
you don't forget.

This kind of solution is more flexible than the OO
style solution, since you can write many different
kinds of 'visitor' style functions without invading
your data descriptions. The downside is that the
code for each kind is scattered through the program,
whereas with classes its localised lexically.

Which solution is best depends on how homogenous
your object kinds are. If they're all instances
of a single abstraction -- use classes.

If they're heterogenous objects -- use summation.

You can of course mix both solutions together -- abstract
what really is abstract, and unify what is not 
using variants.

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


  reply	other threads:[~2004-08-14  7:39 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-14  0:03 chris.danx
2004-08-14  7:38 ` skaller [this message]
2004-08-14 16:28   ` John Prevost
2004-08-14 17:17     ` skaller
2004-08-18 12:04     ` chris.danx
2004-08-18 19:47       ` John Prevost
2004-08-18 22:21       ` skaller
2004-08-16  4:58 Jeff Schultz

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=1092469137.29139.564.camel@pelican.wigram \
    --to=skaller@users.sourceforge.net \
    --cc=caml-list@inria.fr \
    --cc=chris.danx@ntlworld.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;
as well as URLs for NNTP newsgroup(s).