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