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

Dirk Thierbach a écrit :

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

Well it's all a question of not losing patience and switching to a non-object
representation :)

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

I wouldn't bet on that :)

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

But there is an excellent mapping between containment in the modeled
world, and logical containment in the objects.  Hence, I'd like to have
the contents of an object as part of its state.  Properties of an object
may change depending on what they contain, where they are contained or
what objects they are contained with.

For instance, a wooden box containing a bronze statue will be heavy,
cheese contained in a hot oven will melt and hydrogen peroxide contained
in a bottle also containing acetone will, well, get you in trouble.

And most actions in an adventure game involve shifting things around
and the occasional state change now and then.

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

I'm actually working on a multi-dispatched language and I find it
a little bit over-hyped.  It helps with dispatching, but once you've
dispatched and got the objects with the types you want, you still have
to decide what to do and issue individual commands to the implicated
objects, and then collect back the results.

Provided that you have some representation of the types as values
(say as variant tags) you could as well pattern-match on the tuple of types
representations and on the verb.  This is not very scalable, so you could
hack a hand-made dispatch mechanism.  And, certainly, the properties you want
to dispatch on might not be easily representable in types, so your multiple-dispatch
needs guards.
-- 
Berke DURAK


      reply	other threads:[~2008-02-27 10:26 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
2008-02-27 10:26       ` Berke Durak [this message]

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=47C53ABC.30202@exalead.com \
    --to=berke.durak@exalead.com \
    --cc=caml-list@inria.fr \
    --cc=dthierbach@gmx.de \
    /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).