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

Stéphane Ducasse stephane.ducasse at inria.fr
Fri Apr 1 21:07:20 CEST 2011

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