Don't forget that there can be more than one singleton object in a program.
Edward On 3/15/07, Gary S. Thompson <[EMAIL PROTECTED]> wrote:
Edward d'Auvergne wrote: > On 3/14/07, Chris MacRaild <[EMAIL PROTECTED]> wrote: > >> On Tue, 2007-03-13 at 19:51 +1100, Edward d'Auvergne wrote: >> > Gary, >> > >> > I've written some unit tests which are located in the file >> > 'test_suite/unit_tests/data/__init__.py'. Would you know what >> > modifications I need to apply to make these tests run? These tests >> > are for the methods of the Data singleton class (the relax data >> > storage object) which is located in 'data/__init__.py'. I haven't >> > used the statement 'from x import Data' for this class so it is the >> > legal and ubiquitous usage of an __init__.py file. Would >> > 'unit_test_runner.py' handle this code? >> > >> > Thanks, >> > >> > Edward >> > >> > >> > P.S. These tests demonstrate the utility of subclassing the singleton >> > and is one reason I was arguing for the use of the class import rather >> > than reference import. >> > >> >> It is of course correct that the Singleton implimentation I proposed >> does not allow for subclassing. This however might well be seen as a >> design feature, given the well known conceptual problems with >> subclassing Singleton. Essentially, subclassing violates the Singleton >> Design Pattern: >> >> class Singleton: >> def __new__(self): >> ... >> >> class Sub(Singleton): pass >> >> >>> a = Singleton() >> >>> b = Sub() >> >>> isinstance(a,Singleton) >> True >> >>> isinstance(b,Singleton) >> True >> >>> a is b >> False >> >>> a == b >> False >> >> ie. we have 2 instances of Singleton that are not the same thing, and >> not even equal! If this is the behaviour you want, then you need >> something other than Singleton. On the other hand, if you really want >> Singleton, then you can't also hope for subclassability. > > > Actually one is an instance of Singleton and the other is an instance > of Sub. This can be useful for two reasons. Firstly new properties > and functionality can be added to the object and the new singleton > object used for completely different purposes (the Data class doesn't > contain that much, it's mainly the PipeContainer objects rather than > the Data singleton which makes it interesting as the relax data > storage object). So by subclassing Data (and replacing or removing > the add_item() method), you can instantly have a dictionary type > singleton which can be used for anything. Secondly a new and second > singleton can be created for comparison and for isolated testing of > the methods of that singleton without having to worry about corrupting > the object. > > As this issue appears to be an impasse, I propose a vote on the > subject. Any relax developer can vote on the issue by responding to > this message. The parent thread of all these discussions is my > message with the subject "The singleton design pattern for the old > 'self.relax.data' data structure" located at > https://mail.gna.org/public/relax-devel/2007-03/msg00012.html > (Message-id: > <[EMAIL PROTECTED]>). > A second minor thread was started at > https://mail.gna.org/public/relax-devel/2007-03/msg00038.html > (Message-id: > <[EMAIL PROTECTED]>). > > The two options to vote for will be labelled A and B. They are as > follows: > > A: The relax data storage structure is a singleton which is imported > as a class from the 'data' module. The instantiation in the calling > module then gives a reference to this single object. This code can be > seen in the 1.3 repository line. It is described in the parent thread > (see above). > > B: The relax data storage structure is a singleton which is > instantiated upon loading of the 'data' module, the reference of which > overwrites the singleton 'Data' class name in the module. The > instance reference variable is then imported into the calling module > and renamed. A working implementation does not yet exist. It is > described in Chris' message at > https://mail.gna.org/public/relax-devel/2007-03/msg00013.html > (Message-id: <[EMAIL PROTECTED]>). > > Please read all of the messages in the relevant threads before voting. > All the posts are accessible from > https://mail.gna.org/public/relax-devel/2007-03/threads.html . > > Cheers, > > Edward > my vote is for B the logic is as follows inheritance contract: if class A is a subclass of B class B is an A in all respects singleton contract: if class A is a singleton there can only be one instance of A in the global namespace/interpreter clearly these two contracts are in conflict... as alternative if you must share implementation details between two classes which are singletons delegation will allow this regards gary -- ------------------------------------------------------------------- Dr Gary Thompson Astbury Centre for Structural Molecular Biology, University of Leeds, Astbury Building, Leeds, LS2 9JT, West-Yorkshire, UK Tel. +44-113-3433024 email: [EMAIL PROTECTED] Fax +44-113-2331407 -------------------------------------------------------------------
_______________________________________________ relax (http://nmr-relax.com) This is the relax-devel mailing list [email protected] To unsubscribe from this list, get a password reminder, or change your subscription options, visit the list information page at https://mail.gna.org/listinfo/relax-devel
