[Pharo-project] Announcement real problems - please read and comment.
stephane.ducasse at inria.fr
Sun Apr 3 13:13:27 CEST 2011
On Apr 3, 2011, at 12:30 PM, Tudor Girba wrote:
> 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.
>>>> 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?
> 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.
Yes I thought about that too.
So I will try to see with ben that nautilus register to RPackageOrganizer instaed of SystemAnnouncer.
>>> 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.
> "Problem solving efficiency grows with the abstractness level of problem understanding."
More information about the Pharo-project