mailRe: Vote for the design of the relax data storage object singleton.


Others Months | Index by Date | Thread Index
>>   [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Header


Content

Posted by Chris MacRaild on March 15, 2007 - 16:19:
On Fri, 2007-03-16 at 01:50 +1100, Edward d'Auvergne wrote:
On 3/16/07, Chris MacRaild <c.a.macraild@xxxxxxxxxxx> wrote:
On Fri, 2007-03-16 at 01:00 +1100, Edward d'Auvergne wrote:
On 3/15/07, Chris MacRaild <c.a.macraild@xxxxxxxxxxx> wrote:
On Thu, 2007-03-15 at 00:09 +1100, 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.

The definition of inheritance is that an instance of the subclass is
also an instance of the parent class. ie. b is an instance of both Sub
and Singleton. Inheritance from a Singleton class is therefore a 
logical
contradiction.

That is actually incorrect!

Sorry to drag this on, but I'm not incorrect here, and its a fairly
fundamental point of OO philosophy and practice that is well worth
getting right. This is pasted directly from my Python command line (the
interpreter does not lie!):

class A: pass
...
class B(A): pass
...
a= A()
b = B()
isinstance(a,A)
True
isinstance(a,B)
False
isinstance(b,B)
True
isinstance(b,A)
True

Because B is a subclass of A, all instances of B are also instances of A

The 'isinstance()' built-in function will return true if object x is
an instance of the supplied class or, importantly, a subclass.  This
is what it's docstring says.  Try the following instead (after
reissuing the above statements):

a is b
False
hash(a)
-1217311764
hash(b)
-1214788020
id(a)
-1217311764
id(b)
-1214788020

If b was the same instance as a, then the first statement would return
true.  The two hash() statements show that a and b are different.  The
two id() statements show that they occupy different locations in
memory - the number is the object's memory address.  Another test is
populating the empty containers:

a.x = 1
b.y = 2
dir(a)
['__doc__', '__module__', 'x']
dir(b)
['__doc__', '__module__', 'y']

The instances a and b are very much different!

This is all true, but misses the point. a and b are different objects,
but they are of the same type:

type(a) is type(b)
True

and both of them are instances of the parent class A. So to go back to
where we started: for almost any implimentation of Singleton

single = Singleton()
class Sub(Singleton): pass
...
sub = Sub()
isinstance(sub,Singleton)
True
isinstance(single,Singleton)
True
sub is single
False

This breaches the Singleton design because we have two *different*
objects that are both instances of the Singleton class.


To put this in terms of the favourite metaphore, because apple is a
subclass of fruit, all apples are also fruits (ie. all instances of
class Apple in also instances of class Fruit). Even if you have several
different apples, this does not make them any less fruity.

Instance refers to a non-exclusive relationship between class and
object: many different objects can be instances of the same class and
any one object can be an instance of many different classes. Inheritance
is the mechanism of this non-exclusivity; Singlton seeks to limit it.
Hence the two are incompatible when applied to the same object.

Chris


Edward





Related Messages


Powered by MHonArc, Updated Thu Mar 15 17:40:41 2007