[ENH] EventEnhancement-nk

Ned Konz ned at bike-nomad.com
Wed Jun 18 14:58:20 UTC 2003


On Tuesday 17 June 2003 04:30 pm, Andreas Raab wrote:
> > Meanwhile, does anyone else want to weigh in on this topic?
>
> Just because you are asking I think that the model that the event
> framework follows is fundamentally flawed. I tried to explain that
> to Rob long ago - the problem you're discussing is ownership of the
> event/action pair. With strong refs you say it's owned by the
> signaler, with weak refs it's owned by nobody. Both doesn't work.

Ah, I thought we'd hear from you. Thanks for commenting!

> The only object that can really own it is the *performer* of the
> action (this is somewhat similar to regular message sends where the
> receiver *owns* the selector/method pair and the sender *knows* the
> name - in events it's the signaler who needs to know and the
> performer who needs to own). In this sense, the event is a trigger
> for a "method" (action) and if you think about it that way then
> it's clear that neither the signaller nor any third party can
> really own it. But it still needs to be owned by someone or else
> you'll just randomly GC it.

This makes sense.

> In technical terms, the association between signaler and
> registration must be weak (the signaler "knows" about the
> registration but it doesn't own it) whereas the association between
> performer and registration must be strong (the performer owns the
> registration). If done right (e.g., no hard references from the
> registration to anyplace else) everything works just the way one
> expects. In *all* circumstances.

This is actually only a minor change from what we have now, right?

That is, now we have this:

signaler when: #evt send: selector to: performer.
signaler actionMap
	IdentityDictionary(#evt -> WeakMessageSend(selector->performer))

and we need this:

signaler when: #evt send: selector to: performer.
signaler actionMap
	WeakValueDictionary(#evt -> MessageSend(selector->performer))

-- 
Ned Konz
http://bike-nomad.com
GPG key ID: BEEA7EFE



More information about the Squeak-dev mailing list