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

Schwab,Wilhelm K 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.

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?


More information about the Pharo-project mailing list