Igor Stasenko wrote > 1. during startup, you have to be very careful about dependencies > between services, > the errors like using uninitialized service(s) makes image > unrecoverable (because VM crashing). > For example , putting 'Transcript show: ' before freetype initialized > may kill an image, > beyond the point of recovery. The hardest part in it, that since > everything is late bound, it sometimes really hard to put > initialization in right order. And loading any new code in image will > also contribute to chaos > of interdependencies, unless all developers know that they should not > use facility A before facility B is properly initialized. And the only > way to do it is to add own checks and one more #startup method, > which 'enabling' your service after all dependencies initialized. > But the problem is that the longer chain of initialization gets, the > more chances that something will go wrong (as well as getting lost in > order of dependencies).
Just shooting from the hip, isn't that the same problem that more or less all unix os-es have on start up, what parts of systems are alive at particular moment and which ones are not. Instead of hard wiring all dependencies, maybe introduce different run levels, and roughly divide registered start up actions based on the run level? ----- http://www.cloud208.com/ -- View this message in context: http://forum.world.st/Global-session-object-tp4650371p4650576.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
