Stef, 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. HTH. Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse [stephane.ducasse@inria.fr] Sent: Friday, April 01, 2011 3:07 PM To: Pharo Development Subject: [Pharo-project] Announcement real problems - please read and comment. 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. Problem 1 - 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 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? Stef