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

Stéphane Ducasse stephane.ducasse at inria.fr
Sun Apr 3 13:13:27 CEST 2011


On Apr 3, 2011, at 12:30 PM, Tudor Girba wrote:

> Hi,
> 
> 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

Yes this was the problem number 1 of my original mail. 
What I do not understand is why a 
	ifCurtailed: [ emit and process next announcement does not solve the problem]



Now we also have the problem number 2.

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

Yes this is what I think. 

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

ok

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

Yes I thought about that too.
So I will try to see with ben that nautilus register to RPackageOrganizer instaed of SystemAnnouncer.

> 
> Cheers,
> Doru
> 
> 
> 
>>> 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
> 
> --
> www.tudorgirba.com
> 
> "Problem solving efficiency grows with the abstractness level of problem understanding."
> 
> 
> 
> 




More information about the Pharo-project mailing list