[Pharo-project] Announcement real problems - please read and comment.
stephane.ducasse at inria.fr
Fri Apr 1 21:07:20 CEST 2011
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