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

Stéphane Ducasse stephane.ducasse at inria.fr
Sat Apr 2 12:02:21 CEST 2011


Gofer new
	squeaksource:  'PharoTaskForces';
	package: 'ConfigurationOfRPackage';
	load
	
ConfigurationOfRPackage project  load: '1.0'

load RPackage in latest 1.3

Stef


On Apr 1, 2011, at 10:36 PM, Henrik Sperre Johansen wrote:

> 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