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