Edward d'Auvergne wrote:
> On 3/14/07, Chris MacRaild <c.a.macraild@xxxxxxxxxxx> 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:
> <7f080ed10703070006s309a1e1do38e621f48d8f6d9e@xxxxxxxxxxxxxx>).
> A second minor thread was started at
> https://mail.gna.org/public/relax-devel/2007-03/msg00038.html
> (Message-id:
> <7f080ed10703130151u6702d44ap7e75240e70893492@xxxxxxxxxxxxxx>).
>
> 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: <1173263918.8066.238.camel@mrspell>).
>
> 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: garyt@xxxxxxxxxxxxxxx Fax +44-113-2331407
-------------------------------------------------------------------
Re: Vote for the design of the relax data storage object singleton.