Hi,
yes you explained that very well. That's what I suggested to (at runtime
check the hierarchy). But honestly, even more than one instance of a
singleton hierarchy does not really shock me. The best would be to have the
choice (singleton for a whole hierarchy, or less strictly, just per class).
Jean-Noel
On Mon, Feb 22, 2010 at 1:33 AM, thron7 <[email protected]>wrote:
> > 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
