Marcel --

Well, I kind of like this approach. I have always believed there should be
more "algebra" in OOP. And putting more into Smalltalk was one of many
projects that we never quite got to in the 70s. Dan has been thinking about
this as well with his ideas about a "basic Squeak".  That is, there should
be a generic set of "act as" "powerful messages" that constitute the core
of Squeak (and in which beginners can live and prosper). We can see some of
this in the "end-user players" which are a kind of super object that are
simultaneously "objects", "graphemes", "containers", and "roles in a
simulation". I have always liked the "big class object with very few
subclasses" as opposed to the other way round. Another way of thinking
about this is that in an ideal end-user system, many subclasses would be
for pragmatics and hidden from view ...

Cheers,

Alan
-------

At 3:26 PM -0000 12/16/98, Marcel Weiher wrote:
>Alan,
>
>this maybe another red herring (the frequently discussed
>'interfaces/protocols' one), but it seems to me that what kind of
>object an instance *is* is not really an appropriate question in most
>situations.  The question should be what kind of object it can *act
>as*.  This reminds me of the short definition of gerunds in the
>english language:  a verb that acts like a noun.
>
>The only way I see of accomplishing this would be with some kind of
>formal protocol mechanism, which could also be used to succinctly +
>declaratively (!) state some delegation situations:  "Class A
>implements protocol B by delegating it to instance variable C
>(self-sends are mapped to composite/delegate)".  So actually, this
>may be two red herrings in a single message :-)
>
>Marcel
>
>> Actually one of the central mechanisms in most object oriented systems
>> does
>> supply a facility for dealing with "dynamic object compositions"
>and does
>> make "Object composites" into real objects. It's just that "no one"
>> (meaning with very few exceptions) has tried to flesh out the facility.
>> What am I referring to? Why, *instances* themselves. What they are is
>> precisely an object that is a composition of objects. What obtains
>right
>> now is the possibility of carrying out some of your yearnings, but the
>> barriers (especially in Squeak) are currently more of an awkwardness of
>> approach and a lack of some important ways to delegate messages to the
>> composite, than more substantial roadblocks. Right now, there is a
>> tendency
>> to revert to "data-structure" programming for compositions (e.g. toss
>> the
>> composite into a collection) and this holds back progress.
>>      This is a nice job for metaprogramming, and I'm hoping we can
>exhibit
>> some real improvements in this area in calendar '99. I would like to
>> solicit ideas about this that can help the design. One of the most
>> interesting "algebraic" areas parallels that of the problems of
>multiple
>> inheritance: what *kind* of object is an instance that is being
>used as a
>> composer? The instance (at least in Squeak) belongs to a class by
>> definition,  but one might want to derive some additional
>"classness" from
>> the objects in the instance, etc. (Please folks, rise above the
>tendency to
>> start debating "prototypes vs classes" again -- this is a red
>herring in
>> almost all areas and has almost nothing to do with the current
>discussion
>> ...).