You can have a back-door to replace singletons if you want to. That's even easier to add to Singleton. For now though, keep in mind that because of the stew of dependencies between classes in the framework, you really need to restart the app or implement a reset protocol, otherwise something might break when you replace a singleton after startup.
That's why Mike Labriola is saying you can't unit-test the framework per-se. I agree under that definition, and the question is, who will fix that faster: folks trying to modify the framework as is, or folks who will help me with my re-write. On 2/7/12 10:09 PM, "Martin Heidegger" <m...@leichtgewicht.at> wrote: > On 08/02/2012 15:02, Alex Harui wrote: >> One way is to define another set of mixins that get initialized before >> the SystemManager starts registering singletons. >> In my whiteboard re-write, the Singletons will probably be defined in >> some manifest, will only register just before first use, and there >> will be an event to give you a definite chance to register replacements. > That will not enable unit testing. In unit testing the "instances" have > to be replaced before and after each unit to be tested. > In other words: A lot of times not just once at startup. > > yours > Martin. -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
