[Pharo-project] Playing with a declarative startup/shutdown subscription mechanism

Stéphane Ducasse stephane.ducasse at inria.fr
Sun Aug 5 23:37:17 CEST 2012


I have the impression that you will need a finer order at least for the kernel.
so putting
> SomeClass>>startUp: quitting
> 	<systemShutdown: #kernel priority: 1000>
> 	self blahblah.

looks to me the way to go and yes we should clean that part two.

Now what is the gain to have pragma and not just a class side method returning a number?

Stef

> Hi!
> 
> Last days I was playing to replace the image startup/shutdown mechanism via a pragma subscription because I was pissed off with how difficult is to integrate the change of a new startup in the system. The idea is:
> - reduce the mess on subscription/unsubscription, initialization, etc
> - reduce dependencies of external packages in core packages.
> 
> This way, if you want to subscribe a class side method to be executed on startup, you annotate it:
> 
> SomeClass>>startUp: resuming
> 	<systemStartup: #application>
> 	self blahblah.
> 
> SomeClass>>startUp: quitting
> 	<systemShutdown: #kernel>
> 	self blahblah.
> 
> 
> Now, instead of an order in classes startup, I played with the idea of having run levels (which I named #kernel, #application and #user because I was not inspired :P).  Then I replaced the whole system startup and It's working...
> 
> The code is very simple, you can have a look at the category System-Tasks which can be downloaded from:
> 
> MCGemstoneRepository
> 	location: 'http://ss3.gemstone.com/ss/PharoTaskForces'
> 	user: ''
> 	password: ''
> 
> SLICE-Issue-666-Playing-With-startup-GuillermoPolito.2
> 
> 
> Be careful, that package contains the startup code + the replacement of the old startup by the new one :).
> 
> Now, I'd like to have some feedback, u like it? u buy it? which should be the names for the run levels? how many run levels should we have? :P
> 
> Cheers,
> Guille




More information about the Pharo-project mailing list