[Pharo-project] Announcement real problems - please read and comment.

Tudor Girba tudor.girba at gmail.com
Sun Apr 3 12:30:41 CEST 2011


I think that this dialogue goes in too many directions, so I will try to provide a summary. Maybe this helps.

As I understand, Stef has the following problem:
- there is one announcer with two listeners
- the problem is that if the first listener raises an error, the second listener is not announced anymore
- thus, the base system can be broken simply by creating an extra listener that raises an error

As a solution, he proposed the idea of introducing the order of announcements.

Igor and Henrik had strong arguments against this solution. I agree with them. They suggested to either decompose the announcements more fine grained, or as you are pointing out now to layer them. I think this is the best solution, and like that we can have the basic announcements to be private.

However, the original question still remains valid. I am not quite sure what the solution is, but the idea of Denis of using asynchronous announcements sounds interesting. On the other hand, if I mess up something in the private workings of the kernel, my image will be broken, and that is expected.

More inside

On 3 Apr 2011, at 10:40, Stéphane Ducasse wrote:

>>>> 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.
>>> Because
>>> 	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?
>>> Stef
>> 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:
>> anAnnouncer
>>       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?

This does not fix your problem. Henrik simply looked at the code and he saw that it would be better to use the message passing instead of the block.

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

That could be the case, but I think the solution we have now is Ok to bootstrap.


>> It also has the added benefit you can make them weak if you want :)
>> Cheers,
>> Henry
>> 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.
> Stef


"Problem solving efficiency grows with the abstractness level of problem understanding."

More information about the Pharo-project mailing list