Josh Flowers wrote:
> > Dwight Hughes wrote:
> > I find it much more productive to think about methods as adding
> > *behavior* to an object rather than as ways to push bits of the object
> > around. [.....]
> 
> 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? Which is harder to use and maintain: a "dead" data
structure like an array (defined only as a particular group of bits in
memory) with 100 different manipulator functions which all manipulate it
(or parts of it) as a formatted group of bits -- usually with the
meaning of these manipulations and what the bits are being treated as by
the particular manipulator function being implicit at best (is this part
being treated as a string, bitfield, float, integer, character, machine
word, subarray any of these, what? (thus the spectre of strong typing
rears its ugly head)), or a single higher level object that you can just
interact with (which internally might be defined as an Array, but who
cares?)? If any object has behavior, they should all have behavior (or
at least they should all have behavior if desired). Otherwise we get
back into the business of pushing bits around with a broom -- as so many
languages do. 

If what you are really asking is "should we be able to maintain the
behavior (methods) we add to an object just to support a particular
class or application _separate_ from the fundamental general behavior
the object needs to behave as its particular kind of object?" then I
would tend to agree. This would require something like a package level
loading/unloading mechanism, cutting across class boundaries, allowing
individual methods to be defined/overridden for classes but used only
local to the package.

> What might be needed is a system that separates behavior methods
> from state methods.  That way objects could be passed easily between
> modules (actually probably not modules the way we think of them now,
> but something similar) by allowing the modules to define an objects
> behavior methods, but having the state methods travel with an object.
>  Assuming that state methods are not nearly as prone to change as
> behavioral ones (and that is truly an assumption, I don't have any
> facts, or 20 years of experience to back it up), you would have a
> more stable system than if you include both state and behavior in an
> object.

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.

-- Dwight