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

Henrik Sperre Johansen henrik.s.johansen at veloxit.no
Fri Apr 1 22:36:32 CEST 2011


On 01.04.2011 21:07, Stéphane Ducasse wrote:
> 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?
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.

> 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.
The initialize method of PackageOrganizer in RPackage-Core calls 
registerInterestToSystemAnnouncement, which is an extensions in 
RPackage-SystemIntegration.

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

PPPS. Is the code for Nautilus available anywhere?



More information about the Pharo-project mailing list