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