> But back to the extending singleton problem. I don't see a clear solution > for extending singletons (have two instances of a singleton is really no > solution!). So I think we should keep the current solution.
I'm not sure about this. The issue here is to *derive* from a singleton on the class level, which seems like a valid idea to me. If you want a refined child class, it shouldn't matter that the parent is a singleton class. It might be sensible to demand that the child class is also a singleton. But what you are saying is that singleton classes are effectively final. The issue you are actually raising is that of run time *instances* of such a derived class. That's a different problem. Maybe that could be dealt with in the qooxdoo run time, e.g. by checking for another instance polymorphically (i.e. along the class hierarchy) when the constructor of a singleton class is invoked. That way only a single instance of that *hierarchy* can be instantiated. To do that the object registry could keep a list of instantiated singeltons (maybe it does that already). T. ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
