[Pharo-project] Announcement real problems - please read and comment.
bschwab at anest.ufl.edu
Sat Apr 2 15:05:41 CEST 2011
This sounds like a job of a unit (acceptance) test :) One suggestion was to break the rename into pieces. I follow the thinking, but fear it will make the problem worse.
Dolphin has a really slick event system, which was perhaps more of a big deal c 1997 than it is now. One thing that became clear early on is that events are a best effort system, and I ended up adding some messages to, at the expense of performance, provide a hardened version of the system. It's no big deal: I just trapped errors so that down-stream receivers would get their events. The events in question caused network activity, so failures were far more common than one would expect renaming a class.
However, I think what you need here is a #rename:to:in: event that provides both old and new class names and the package that owns the affected class (the renamed version goes in the same package, right???). I **think** that, combined with some pre-rename checks (Is this going to work? If not, stop now...) will take care of the problem.
From: pharo-project-bounces at lists.gforge.inria.fr [pharo-project-bounces at lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse [stephane.ducasse at inria.fr]
Sent: Friday, April 01, 2011 3:07 PM
To: Pharo Development
Subject: [Pharo-project] Announcement real problems - please read and comment.
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.
- the second announcement was never sent, because the first one broke the second was blocked.
>> we should make sure that if an announcement leads to an error, other annoucements on the same emit should pass
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
- 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?
More information about the Pharo-project