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

Igor Stasenko siguctua at gmail.com
Sat Apr 2 13:04:35 CEST 2011


On 1 April 2011 22:36, Henrik Sperre Johansen
<henrik.s.johansen at veloxit.no> wrote:
> On 01.04.2011 21:07, Stéphane Ducasse wrote:
>>
>> Hi guys
>>
>> We found a problem with ben and RPackage.
>> Here is the scenario and may be you can help us finding the right
>> solutions.
>>
>> Nautilus renames a class
>>        the class got renamed
>>        ->  an announcement is raised
>>                - nautilus gets notified, it asks rpackageOrganizer (which
>> also listens to the same event)
>>                                ->  rpackageOrg breaks because the class if
>> was referting to does not exist anymore.
>
> This sounds like mess in logic.
> You ask package of class that is in the process of being renamed?
> Why would you expect this to work?
> Use more announcements to represent multiple steps in renaming process, for
> example both ClassRenaming and ClassRenamed.
> Changing it's package is something you do as an action that should be _part_
> of renaming, while updating it's location is something you would do _after_
> renaming is complete.
>

I want to add that there should be single place handling this event.
And if there multiple subscribers, they should not operate with same
data. Otherwise you will have many problems.

>> Problem 2
>>        If rappckageOrganizer would be reached before Nautilus we would not
>> get any problem (beside the problem 1).
>>
>>        - we spent one hour playing with alternatives.
>>        We thought that if RPackage would points to classes a rename would
>> not break the system.
>>        While this is true for class, the same problem will occur for
>> method rename since compiled method are not shared and a new compiled method
>>        is compiled.
>>
>>        - If RPackage was as deep inside the system as superclass/subclass,
>> the invariant would be directly maintained by the system
>>        and we would not have to rely on announcement. But now we should
>> find a solution.
>>
>>        >>  may be we should be able to say that an announcement has a
>> priority.
>>        Typically we would like to say that when RPackageOrganizer
>>  register interests it should be served first.
>>        we could have a systemLevel priority that could be specified on
>> registration.
>>
>>        what do you think?
>
> Bad, bad, bad, bad, baaaaaad idea.
> I know from experience that once you concede that announcement listener
> order should matter, you are setting yourself up to fail.

Exactly.

> Although you know one listener _HAS_ to respond first, there will always be
> someone else who want to respond "firstester".
> Not to mention the logic in this case becomes next to impossible to
> follow/debug/ maintain, as you've already experienced.
>
> For a proper solution, introduce more Announcements for actions which should
> happen in different phases of a process, as explained above.
>
> Cheers,
> Henry
>
> PS. I was unable to load RPackage.
> The initialize method of PackageOrganizer in RPackage-Core calls
> registerInterestToSystemAnnouncement, which is an extensions in
> RPackage-SystemIntegration.
>
> PPS. There's a neat method called #on:send:to:,  which would be perfect for
> the different actions in RPackage-SystemIntegration.
>
> PPPS. Is the code for Nautilus available anywhere?
>
>



-- 
Best regards,
Igor Stasenko AKA sig.



More information about the Pharo-project mailing list