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

Stéphane Ducasse stephane.ducasse at inria.fr
Sat Apr 2 09:19:23 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.
> This sounds like mess in logic.
> You ask package of class that is in the process of being renamed?

No
	Just the browser ask the package its classes to display them and the package has not been refreshed because this is done by the announcement
	that is after the one that led to a refresh

> Why would you expect this to work?
> Use more announcements to represent multiple steps in renaming process, for example both ClassRenaming and ClassRenamed.
> Changing it's package is something you do as an action that should be _part_ of renaming, while updating it's location is something you would do _after_ renaming is complete.

Probably we will check that.


>> 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?
> Bad, bad, bad, bad, baaaaaad idea.
> I know from experience that once you concede that announcement listener order should matter, you are setting yourself up to fail.
> Although you know one listener _HAS_ to respond first, there will always be someone else who want to respond "firstester".
> Not to mention the logic in this case becomes next to impossible to follow/debug/ maintain, as you've already experienced.
> 
> For a proper solution, introduce more Announcements for actions which should happen in different phases of a process, as explained above.
> 
> Cheers,
> Henry
> 
> PS. I was unable to load RPackage.

In which image?

> The initialize method of PackageOrganizer in RPackage-Core calls registerInterestToSystemAnnouncement, which is an extensions in RPackage-SystemIntegration.

Yes this is normal. 
I will try to load it to check. May the configurationOfRPackage has not been updated

> PPS. There's a neat method called #on:send:to:,  which would be perfect for the different actions in RPackage-SystemIntegration.

But why should we rely on a different event system?

> PPPS. Is the code for Nautilus available anywhere?
Yes in Nautilus on squeaksource.





More information about the Pharo-project mailing list