[squeak-dev] Re: How about... something completely different?(Re: Re: On traits composition)

Göran Krampe goran at krampe.se
Wed Dec 9 17:40:49 UTC 2009


Hi all!

Alejandro F. Reimondo wrote:
> imo the most enlightment fact is that the "whole" is NOT an object,
> it is not a composition, and it is not it's contents.
> We have it in Smalltalk and it is not the global Smalltalk,
> as a school of fishes is not aSet of Fish instances.

I admit not entirely grokking what you Alejandro tried to communicate in 
the previous post, but I do agree that it is about "complementary" 
schemes, and not something *entirely* different.

Anyway, I sat down discussing this thread with Jonas Beckman and others 
here at MSC and we made lots of interesting connections.

At the moment I am looking at a rather trivial little "package" to 
experiment in this direction. Let's create class Cell, inheriting from 
Object. Let's give it a DNU implementation so that it can expose its 
Parts as part of its external protocol. Let's call it's internal objects 
"Parts" (hey, this word is not that good, suggestions?).

Further:

"Receptor" = a subset of the protocol of one of the parts of the Cell, 
being exposed as part of the protocol of the Cell. Thus if a Cell has 
three parts held as ivars (contrary to Ted's Membrane I want a Cell to 
be more or less a regular object), it can have 0-3 receptors, one 
possible receptor per part.

Now... we can imagine various ways of defining the receptor for a given 
part:
	- Full receptor. This is "handle all messages that I don't handle", in 
other words full delegation.

	- Partial receptor. Using either activation/suppression (whitelist or 
blacklist of selectors) we specify a subset of selectors that we 
delegete. Ideally we do this late bound.

	- Delegated receptor. This is "let the part decide".

...anyway, an example would be to define the receptor for a given part 
as simply a Set of selectors, either a blacklist or a whitelist.

And oh, yeah, the receptors probably need to be ordered to avoid 
conflicts (other ideas?).

Summary: We refine the "delegation" concept by being able to delegate 
only a subset of messages. We call this subset the "Receptor" of the part.


Second part: Let's also (as Alan Kay suggested in Ted's Membrane paper) 
add a TupleSpace-ish communication model inside the Cell that it's 
"parts" can *optionally* use to loosely communicate with the Cell and 
with each other.

The parts can talk to each other and the Cell using just plain "object 
references" BUT... in order to more easily make them reusable and 
loosely coupled we could add an internal "message bus" in the Cell - and 
the most generic way to do that is probably to mimic a TupleSpace.

Ok, sorry for my confused ramblings - but that is about it. I think I 
will hack this up to play with.

And I rejected ideas Ted mentioned like dependencies, "whole" etc. I 
also think Alan is "right" to propose a loose messaging metaphor inside 
the Cell, contrary to Ted's idea of very close coupling. At the same 
time a Cell is meant to offer a spectrum - either you don't use 
receptors and don't use the tuplespace-thing - and then, tada, it is 
just a regular Object!

All feedback/brainstorming appreciated.

ciao, Göran




More information about the Squeak-dev mailing list