[Pharo-project] About announcements

Stéphane Ducasse stephane.ducasse at inria.fr
Mon Jan 2 14:35:02 EST 2012


Can one of you turn the following list into bug entries?
So that we can make progress by killing them one by one?

Stef

>>>> agreed here. I would even leave a semaphore.
>>> I think it is overlooked by Henrik.
>>> It also don't needs a lazy initialization in #protected: , since in
>>> #initialize it can just create a ready for use fresh
>>> synchronization object.
> 
> A semaphore might block, because an announcement could register
> another announcement. So probably the Mutex would be the right thing
> to use.

But apparently Mutex is broken :(


> 
>>>> 4. It creates a copy of the collection of all the subscriptions: This
>>>> is rarely useful and wouldn't be necessary if an immutable data
>>>> structure was used.
>>>> 
>>> propose better solution how to deal with situation when during
>>> handling an announcement,
>>> your handler unsubscribing from announcer.
> 
> Array. Slower for registration, but faster at announcing (the common operation).
> 
>>>> 5. It iterates over all announcements, it doesn't even try to group
>>>> announcements of the same kind.
>>>> 
>>> it is pointless to group them, and makes no real difference.
>>> Because announcer doesn't knows what kinds of announcements will be
>>> announcement,
>>> and it knows only about subscriptions.
>>> Suppose i have a subscription to Announcement. And i announcing
>>> AnnouncementA (a subclass of it).
> 
> Fair enough, probably it doesn't matter.
> 
>>>> 7. It then tests each announcement if it matches, again it doesn't
>>>> even try to group the announcements of the same kind. Aside, the match
>>>> test was changed so that it doesn't allow instance-based announcements
>>>> anymore, breaking some of my code.
>>>> 
>>> what is instance-based announcements?
> 
> If you have a client with 1000 different possibly dynamically changing
> properties and you want a way to register for announcements of a
> single property. The current implementation forces you to create a
> class per property, previously you could fake a "kind of
> announcements" with an instance.
> 
>>> you can use any object as  a subscription selector, just make sure it
>>> understands #handles: message.
>>> i.e.
> 
> No, because the Announcement>>#handles: takes a class, not an instance.
> 
>>>> 9. It then culls the announcement and announcer into the block. Not
>>>> sure why the announcer is useful, after all the block was registered
>>>> with the announcer at some point.
>>>> 
>>> cull there is for passing optional arguments.
> 
> I didn't complain about #cull:, but about the useless announcer passed in.
> 
> Now for me you don't need to change the semantics of the Pharo
> Announcements again. Now for my code I will just use my own
> implementation that has exactly the behavior and performance
> characteristics I need.

Lukas our state of mind is that we want the infrastructure gets better so we like to change 
for a better one if this better one is better.
If everybody has its own version then we do not improve the infrastructure.

Stef





More information about the Pharo-dev mailing list