Moving objects...

Dwight Hughes dwighth at ipa.net
Sat Jul 24 00:59:48 UTC 1999


Josh Flowers wrote:
> > > I agree, that's how I've always thought of it too, but what I'm
> > > wondering is if maybe we haven't gone off the deep end by doing that.
> > >  Should a string really have "behavior", or in the end does that
> > > make our lives more difficult.  Animate objects are much more
> > > difficult to deal with than inanimate ones.
> >
> > I must disagree. Which is more difficult to take for a walk: a live dog
> > or a dead dog?
> 
> You've never met my dog.
> 
> I can walk any dead dog, and the only problem might be the dog is
> too heavy to pull.  Live dogs are a different story all together,
> some well trained dogs are easy, other poorly trained, or worse yet
> those that are trained to attack, are much more difficult to walk.
> The point being "dead" objects essentially can always be used the
> same way.

A better analogy would have been: which is easier to play Frisbee with:
a live dog or a dead dog? (Assuming you have a FrisbeePlayingDog object
to begin with.) My point being, a dead object by itself would seem to be
of little interest, and require more effort to get anything to happen --
the interesting and useful aspect of an object is what it _does_, not
what it's internal structure is. But perhaps I take this notion much
further or more literally than you intended.

                                  > there's no reason to eliminate
> collections, just to split it's methods.  Methods that get or set
> objects within the collection would be considered what I call state
> methods, and are always a part of a collection object.  Methods like
> do: are considered behavior methods, are not considered intrinsic to
> the object itself.

A difficulty I see here is that many methods fall into both categories
-- both changing state and defining behavior. Where (and how) would you
draw the line?

> > Actually the sort of thing you are describing is rather like what is
> > done by the generic functions that make up CLOS and Dylan. Where the
> > structure of an object and the methods that manipulate it are
> > essentially separate entities.
> >
> I've heard of Dylan, not CLOS.  They sound interesting, but the
> structure of the object still needs to be encapsulated.

CLOS (Common Lisp Object System) is where much of Dylan's basic system
design came from. Although originally built on top of Common Lisp, it is
a very powerful language in its own right. There are various good books
covering it and there was a good online intro but I cannot seem to find
it at the moment. Neither CLOS nor Dylan make use of the message passing
paradigm of Smalltalk, so direct comparison is less than exact, but the
overall system structure is much like what you're talking about. Dylan
especially encourages this sort of structuring. But I must say that it
is not a cure for all ills. With a class's behavior spread across a
number of modules it can become difficult to characterize what all a
class does and what might break and how when you change the class --
also, the modules do a good job of hiding common behavior that you would
otherwise factor out and use more generally rather than reinventing each
time around.

-- Dwight





More information about the Squeak-dev mailing list