WeakMessageSend event registration doesn't work with transient
arguments (was [Q] Morphic Color Problems)
John W. Sarkela
sarkela at sbcglobal.net
Mon Jun 16 20:38:26 UTC 2003
My vote is for regular MessageSend objects. (That's why I used them.
:-}>) Having used this mechanism extensively since Steve Messick
introduced it in Smalltalk/V Mac 2.0, I have found that the time spent
figuring out where dependencies should be released invariably led to
improvements in my design and a better understanding of the temporal
dependencies of the subsystems. I have found this to be the case with
the original changed/update mechanism as well.
In my experience, loose coupling defines a de facto session of
observation. Making the (de)registration explicit forces the designer
to be aware of a session of observation and when that session begins
and ends. This becomes particularly important in distributed systems in
which observation may be occurring over remote links. I know from
experience that explicit registration and deregistration as the
demarcation of session boundaries is extraordinarily useful in these
Most of the arguments I have heard for weak registrations fall in the
camp of "I don't want to think about the consequences of
dependency...". In over a decade of use, I have never had the need for
[ :me | 'Sir ', me, ' of the Square Bracket'] value: ':-}>'
On Monday, June 16, 2003, at 08:14 AM, Robert Withers wrote:
> On Monday, June 16, 2003, at 04:18 AM, Chris Burkert wrote:
>> Could we now do something about it? I don't wanna override the events
>> code and the only difficult part to change it is to agree on the
>> names for the messages I think.
> Chris, for now you can use the #when:evaluate: registration method and
> specify a regular MessageSend. So, you would have:
> r := RectangleMorph new openInWorld.
> o := Object new.
> o when: #a evaluate: (MessageSend receiver: r selector: #color:
> argument: (Color black alpha: 0.3)).
> On Sunday, June 15, 2003, at 11:13 PM, Ned Konz wrote:
>> The problem is that the WeakMessageSends we're using (well, my name is
>> all over this, so I guess I'm responsible) hold on to their receiver
>> *and* their arguments weakly.
> Ned, I am equally responsible for this and probably more so since it
> was primarily my argument to include this "feature". IIRC, our
> interest was to help the developer avoid having to explicitly
> deregister event registrations, since it can be a common source of
> uncollected garbage. Static typing is also supposed to help the
>> We've discussed this at length in the past (like back on February 9)
>> and never really did anything about it.
> This really doesn't work as well as I had hoped. We probably ought to
> revert back to the original mechanism which uses regular MessageSends.
> What do people think about this? This would just require us to
> change 3 methods.
> so much for strongly held opinions... :-/
More information about the Squeak-dev