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

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

I'm not sure I follow this, 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.

> 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 is exactly what I'm talking about, I've just taken it one step  
further and stated what kind of methods I feel are fundamental to an  
object, and what objects can be separated out.

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

I've heard of Dylan, not CLOS.  They sound interesting, but the  
structure of the object still needs to be encapsulated.