[Pharo-project] Announcement real problems - please read and comment.
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
>> 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
>> 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
>> 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.
> 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.
> PS. I was unable to load RPackage.
> The initialize method of PackageOrganizer in RPackage-Core calls
> registerInterestToSystemAnnouncement, which is an extensions in
> 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?
Igor Stasenko AKA sig.
More information about the Pharo-project