2009/11/2 Stéphane Ducasse <[email protected]>:
>>>
>> Oh yeah, i seen that code, and Dependents class var in Object class,
>> which is a dictionary of dictionaries...
>> This model, as well as morphic extensions, takes roots from Self's
>> morphic, where you can easily extend
>> any object state by adding new slots to it. In smalltalk we don't have
>> dynamic named slots, and thus we
>> having such ugly crutches :)
>
>
> No it was before that.
> It was because any object could have a dependent (even if model was
> favored)
> so for object the registration was stored in a large table.
>
>>> I hope we don't replicate this scheme, I had understood Announcements
>>> did not thanks to explicit subscription.
>>> Anyway, a bit of archeology is always helpfull when cleaning
>>> Smalltalk...
>>>
>>
>> It is strange, i have a feeling that people think i am being
>> short-sighted or don't understand things,
>> while i'm trying to show the potentional bottlenecks of Announcements
>> framework itself...
>
> no continue I like to see arguments.
> Before consensus arise I like discussions because even lukas can be
> wrong ;D
>

I implemented a new announcer, which covers all functionality of the
original one
(all tests is green) but in addition enables you to subscribe directly via
#subscribe:
and receive #handle: message in case of announcements.
Of course, the decision whether to handle or ignore announcement is up
to subscriber.

Next thing, which i tried to do is to add weak subscriptions.
The syntax, i suggest is simple. As usual, for strong subscription you writing:

announcer on: Announce do: [:ann | ...  ].
(or any other message pattern)

and for weak ones you writing:

announcer weak on: Announce do: [:ann | ...  ].

so, difference is in #weak keyword standing between announcer and
subscription message.
I think this is short and elegant, and doesn't forcing developer to
learn or use different messages to subscribe
weakly.

The most powerful thing with weak subscriptions is, that we don't care
about unsubscribing - the framework
will automatically wipe the subscription entry, once subscriber becomes garbage.

But there is a problem with an implementation of block based
subscriptions (such as #on:do:).
since, in block-based subscriptions, the real subscriber is a block
receiver (a 'self' in block's home context) but not a block itself.

So, we need to reference the block subscription strongly only if
receiver of block is reachable by other means (not via subscription
itself).
The only way how we could do that withotut much hassle is to use ephemerons, but
unfortunately, Squeak VM doesn't supports ephemerons, so support of
weak block-based subscriptions is not possible without ugly hacks ,
like getting inside a block closure and patch its home context state
(to get rid of receiver reference).. which is quite awful and error
prone.. :(


> _______________________________________________
> Pharo-project mailing list
> [email protected]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>



-- 
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Reply via email to