On 1 April 2011 22:36, Henrik Sperre Johansen <henrik.s.johansen@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.