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
Re: Vote for the design of the relax data storage object singleton.