[Pharo-project] Announcement real problems - please read and comment.
stephane.ducasse at inria.fr
Sun Apr 3 10:40:25 CEST 2011
>>> PPS. There's a neat method called #on:send:to:, which would be perfect for the different actions in RPackage-SystemIntegration.
>> I'm trying to understand how this on:send:to: would help us.
>> Nautilus registered to system announcer
>> Now I do not understand why RPackageOrganizer should not register to systemAnnouncer too.
>> And even if we use on:send:to: who can garantee that the on:send:to: will notify first the RPackageOrganizer and
>> not that an announcement will reach the browser before.
>> What was your idea?
> It has nothing to do with registration ordering, but using the proper API.
> If you look at the RPackageOrganizer registrations in RPackage-SystemIntegration, all they do in the action block is send self a message.
> Instead of:
> when: SystemCategoryAddedAnnouncement do: [ :ann | self systemCategoryAddedActionFrom: ann ];
> you write:
> announcer on: SystemCategoryAddedAnnouncement send: #systemCategoryAddedActionFrom: to: self
I do not get what is the difference. Can you explain how this would solve my problem?
I was discussing with luc and noury yesterday and we thought about the following:
The system should be layered in two layers
system (Rename) should emit annoucement to system objects (like RPakcageOrganizer)
UI tools should register not to system but to RPackageOrganizer.
So this is probably the solution but I'm thinking that in the long turn may be pushing packages inside the system wiuthout annoucement
would be better.
> It also has the added benefit you can make them weak if you want :)
> And ugh, why the Announcement at the end of the Announcement names? :/
Who cares for now we have a system on its knees if one annoucnement breaks so to me this is totally useless.
More information about the Pharo-project