caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Dirk Thierbach <dthierbach@gmx.de>
To: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] Objects, dynamic cast, Obj.magic abuse and dragons
Date: Wed, 27 Feb 2008 08:37:26 +0100	[thread overview]
Message-ID: <20080227073726.GA1494@feanor> (raw)
In-Reply-To: <47C43D61.7070905@exalead.com>

On Tue, Feb 26, 2008 at 05:25:05PM +0100, Berke Durak wrote:
> Dirk Thierbach wrote :
>> I think I wouldn't use objects at all in this situation. You're trying
>> to model the location-tree of "physical" things. A tree must be uniform
>> in its contents, but you want to put different things into it. That
>> means you must use an algebraic type, or variants. I'd probably either
>> use a zipper, or connect the tree nodes with "refs" for the non-pure
>> version. 

> You are preaching to the choir.  

I'm not preaching here :-)

> I'm not Gerd Stolpmann and I don't use objects very much because
> every time I try I get seven-page-long errors.

I, OTOH, use them frequently. I also get seven-page-long errors,
but usually I can find the bug nevertheless :-)

> However it seems that objects could be actually useful in situations
> where you have a hierarchy of objects with behaviours, such as a graphical
> user interface made of widgets, or, say, a text adventure.

Yes, they can be very useful in some situations, especially in GUIs.
However, I think they are not useful in the particular situation of
a text adventure.

And I think that the criterion is not having a hierarchy of behaviours
(first, "inheritance is not subtyping", second, as you've seen, you
can run into trouble with static type checking easily), but the criterion
is having substantial state that should be partitioned and decoupled.

This also applies to the text adventure to some degree, but the actual
state is much simpler: Must items will have no state at all, or
at most a boolean like "open/closed". Their *relationship*, OTOH
(i.e. location, attachment) can be described uniformly and globally.
Also, for the actual actions, you need multi-dispatch: The outcome
of the action depends on the verb and multiple items ("tie rope to
railing"). And all this says that single-dispatch statically typed 
objects, like in OCaml, are a bad match for this situation.

- Dirk


  reply	other threads:[~2008-02-27  9:30 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-26 11:35 Berke Durak
2008-02-26 12:14 ` [Caml-list] " Richard Jones
2008-02-26 14:28   ` Berke Durak
2008-02-26 14:48     ` Richard Jones
2008-02-26 14:59       ` Berke Durak
2008-02-27 13:26   ` Tiphaine.Turpin
2008-02-29 10:36     ` Berke Durak
2008-02-29 12:23       ` Tiphaine.Turpin
2008-02-26 12:48 ` ketti
2008-02-26 13:10 ` Berke Durak
2008-02-26 15:07 ` Dirk Thierbach
2008-02-26 16:25   ` Berke Durak
2008-02-27  7:37     ` Dirk Thierbach [this message]
2008-02-27 10:26       ` Berke Durak

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=20080227073726.GA1494@feanor \
    --to=dthierbach@gmx.de \
    --cc=caml-list@yquem.inria.fr \
    /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).