Version française
Home     About     Download     Resources     Contact us    
Browse thread
Objects, dynamic cast, Obj.magic abuse and dragons
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Berke Durak <berke.durak@e...>
Subject: Re: [Caml-list] Objects, dynamic cast, Obj.magic abuse and dragons
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