Re: The python implementation of the "relationships between classes".

[Jerry Zhang]

A general description of my issue.

To my understand, python's feature such as "name-reference-object" and
"garbage collection" system did some of work for you, it makes your life
easier, but you still need to add your explicit application in your code.

For example,
Composition implementation: you may need to do 5 job with C++, but only 2
job with python, the other 3 job is done by python implicitly.
association implementation: You need 3 job with C++, but 1 with python. it
seems python's object's lifecycle handling has reached this level, all you
should do is just "associating and de-association".

Here is exactly of my question, for composition,
 the best code may be you do 2 job explicitly, 3 job done by python
implicitly.
Code_Zero. 1 job(by you) + 4(by python) does NOT work.
Code_one. 2 job(by you) + 3(by python) works. That is the best one.
Code_two. 3 job( by you) + 2 (by python) works too,
Code_three. 4 job(by you) + 1(by python) works too.

Since i am not familiar with python yet, my code most likely would gets
into Code_two or Code_three(Code_Zero is also possible for new guys like
me), though they also work, they are bad code.
What i am looking for is the Code_one example, i thought many OOP
application designer may have met this issue, so a good Code_one reference
is the best choice to start this project.

2011/11/11 Jerry Zhang 

>
>
> 2011/11/11 Chris Angelico 
>
>> On Fri, Nov 11, 2011 at 10:14 AM, Chris Kaynor 
>> wrote:
>> > Continuing this OT discussion, would it be a brain transplant, or a
>> > full body transplant?
>>
>> It's just a rebinding. You don't move the body, you just bind your
>> name to a new body. It's perfectly legal to have two names bound to
>> one body (cf Dr Jekyll and Mr Hyde); if you murder Mr Hyde, you can
>> still access the body through the other name.
>>
>> This is association, not aggregation or composition. You already realized
> that there is difference between these relationship(depending on your
> application requirement). and you are trying to tell me to code a
> aggregation and the composition with the same code.
>
>
>
>> ChrisA
>> --
>> http://mail.python.org/mailman/listinfo/python-list
>>
>
>
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The python implementation of the "relationships between classes".

[Jerry Zhang]

2011/11/11 Chris Angelico 

> On Fri, Nov 11, 2011 at 10:14 AM, Chris Kaynor 
> wrote:
> > Continuing this OT discussion, would it be a brain transplant, or a
> > full body transplant?
>
> It's just a rebinding. You don't move the body, you just bind your
> name to a new body. It's perfectly legal to have two names bound to
> one body (cf Dr Jekyll and Mr Hyde); if you murder Mr Hyde, you can
> still access the body through the other name.
>
> This is association, not aggregation or composition. You already realized
that there is difference between these relationship(depending on your
application requirement). and you are trying to tell me to code a
aggregation and the composition with the same code.



> ChrisA
> --
> http://mail.python.org/mailman/listinfo/python-list
>
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The python implementation of the "relationships between classes".

[Jerry Zhang]

2011/11/11 Terry Reedy 

> On 11/10/2011 9:31 AM, Jerry Zhang wrote:
>
> Unfortunately there is a difference between composition and
>>aggregation in my real word, and my application really care this
>>since it is trying to simulate this real world model, so my system
>>should track this difference accurately, otherwise the system may
>>not work well.
>>
>>For example,
>>a. the Cls_arm and Cls_body may be composition, but not aggregation.
>>My app must ensure that " one arm instance only live with one body
>>instance, if the body instance die, the arm instance must die.
>>
>
> Create the arm as a private member '_arm' of body and make sure that no
> method of body passes out a reference to the arm. (In Python, outside code
> can still grab a reference to the private attribute, but that is a coding
> bug.)
>
> I will point out that in the real world, dead donor transplants are based
> on the fact the parts of the body do NOT have to die when the composition
> does. I will not be surprised if we someday see arm transplants.

Thanks for your comment.
Actually you are mixing the concept. That is aggregation implementation,
which also points out there is difference between aggregation and
composition implementation. You already know that.

>
>
> --
> Terry Jan Reedy
>
> --
> http://mail.python.org/**mailman/listinfo/python-list
>
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The python implementation of the "relationships between classes".

[Jerry Zhang]

2011/11/11 Benjamin Kaplan 

> On Thu, Nov 10, 2011 at 1:06 PM, Jerry Zhang 
> wrote:
> >
> >
> > I just did an example code to describe what i am looking for.
> >
> /**/
> > # ...
> >
> > class Head:
> > def __init__(self):
> > self.size = 5
> >
> > class Hat:
> > def __init__(self):
> > self.color = red
> > def took_on(self, body):
> > self.body = body
> > def took_off(self, body):
> > del self.body
> >
> > class Body:
> > def __init__(self):
> > self.head = Head()
> > def take_on_hat(self, hat):
> > self.hat = hat
> > hat.take_on(self)
> > def take_off_hat(self):
> > hat.take_off(self)
> > del self.hat
> > def go_to_heaven(self):
> > take_off_hat(self)
> > del self.head
> >
> /*--*/
> >
> > In this example, Head and body are COMPOSITION, which means
> > a. A head only live with one body, it can not live with other body. It
> can
> > not even live without body
> > b. If the body go to die, the head also go to die.
> >
> > Body and Hat are aggregation, which means
> > a. A hat live isolate with body, its life circle is isolate
> > b. A hat only live with one body at a specific time, it can not live with
> > two body(association would be more than one)
> >
> > So when the body die, the clean dead should include take_off Hat and del
> > Head, otherwise, the code definition is not prciselly describing the
> > relationship, which may cause a mess system, for example, a body has
> dead,
> > but one hat is still associated with a unreferenced body.
> > A point on this issue, maybe python is smart that the take_off_hat(self)
> is
> > not needed in go_to_heaven() method(i am not sure yet), but the del
> > self.head is sure needed, otherwise, we will have a no_body_head in our
> > ZODB, that is extremely horrible, right?
> >
> > All of these points one, the four kinds of class relationship in UML
> > precisely describe the real word, if the implementation is not precisely,
> > you will have unexpected results.
> > Of course, python may be smart to achieve such goal with less effort,
> that
> > is why i am asking for a code example for all of the four relationships.
>
> You're still misunderstanding Python's object model. del does NOT
> delete an object. It deletes a name. The only way for an object to be
> deleted is for it to be inaccessible (there are no references to it,
> or there are no reachable references to it).
> >>> foo = object()
> >>> bar = foo
> >>> foo
> 
> >>> bar
> 
> >>> del foo
> >>> bar
> 
> >>> foo
>
> Traceback (most recent call last):
>  File "", line 1, in 
>foo
> NameError: name 'foo' is not defined
>
>
> There is no way to force the go_to_heaven method to delete the head
> unless you can make sure that all other references to the head are
> weak references. If you need strictly-enforced relationships, Python
> is probably not the right language for the job- you'll be better off
> with C++ or Java.
>

Thanks for your reply, but i know your point on this before post this
issue. "doing the the job of python's garbage collecting" system is not i
want.
What i am trying to do is a python implementation of the real "composition
implementation".

> --
> http://mail.python.org/mailman/listinfo/python-list
>
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The python implementation of the "relationships between classes".

[Chris Angelico]

On Fri, Nov 11, 2011 at 10:14 AM, Chris Kaynor  wrote:
> Continuing this OT discussion, would it be a brain transplant, or a
> full body transplant?

It's just a rebinding. You don't move the body, you just bind your
name to a new body. It's perfectly legal to have two names bound to
one body (cf Dr Jekyll and Mr Hyde); if you murder Mr Hyde, you can
still access the body through the other name.

ChrisA
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The python implementation of the "relationships between classes".

[Chris Kaynor]

On Thu, Nov 10, 2011 at 2:48 PM, Steven D'Aprano
 wrote:
> On Thu, 10 Nov 2011 14:38:58 -0500, Terry Reedy wrote:
>
>> I will point out that in the real world, dead donor transplants are
>> based on the fact the parts of the body do NOT have to die when the
>> composition does. I will not be surprised if we someday see arm
>> transplants.
>
> And Guido's Time Machine strikes again... not only have there been arm
> transplants, but the first DOUBLE arm transplant was three years ago:
>
> http://www.dailymail.co.uk/health/article-1039587/Worlds-double-arm-transplant-man-gets-teenagers-limbs.html
>
>
> There have been successful *face* transplants. Nothing will surprise me
> now until they do a brain or head transplant.
>

Continuing this OT discussion, would it be a brain transplant, or a
full body transplant?

>
>
> --
> Steven
> --
> http://mail.python.org/mailman/listinfo/python-list
>
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The python implementation of the "relationships between classes".

[Steven D'Aprano]

On Thu, 10 Nov 2011 14:38:58 -0500, Terry Reedy wrote:

> I will point out that in the real world, dead donor transplants are
> based on the fact the parts of the body do NOT have to die when the
> composition does. I will not be surprised if we someday see arm
> transplants.

And Guido's Time Machine strikes again... not only have there been arm 
transplants, but the first DOUBLE arm transplant was three years ago:

http://www.dailymail.co.uk/health/article-1039587/Worlds-double-arm-transplant-man-gets-teenagers-limbs.html


There have been successful *face* transplants. Nothing will surprise me 
now until they do a brain or head transplant.



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The python implementation of the "relationships between classes".

[Ethan Furman]

Benjamin Kaplan wrote:

You're still misunderstanding Python's object model. del does NOT
delete an object. It deletes a name. The only way for an object to be
deleted is for it to be inaccessible (there are no references to it,
or there are no reachable references to it).

foo = object()
bar = foo
foo



bar



del foo
bar



foo


Traceback (most recent call last):
  File "", line 1, in 
foo
NameError: name 'foo' is not defined


There is no way to force the go_to_heaven method to delete the head
unless you can make sure that all other references to the head are
weak references. If you need strictly-enforced relationships, Python
is probably not the right language for the job- you'll be better off
with C++ or Java.


Having said all that, you could do something like:

class BodyPart(object):
_alive = True
def __nonzero__(self):
return self._alive
def die(self):
self._alive = False

class Head(BodyPart):
"will contain things like Brain, Eyes, etc"
size = 5

class Body(BodyPart):
def __init__(self):
self._head = Head()
def go_to_heaven(self):
self._head.die()
self.die()

John_Doe = Body()

if John_Doe:
print "John Doe is alive!"
John_Doe.go_to_heaven()
if John_Doe:
print "uh oh - something wrong"
else:
print "John Doe is no longer with us"
print "and his head is %s" % ('alive' if John_Doe._head else 'dead')
--
http://mail.python.org/mailman/listinfo/python-list

Re: The python implementation of the "relationships between classes".

[Terry Reedy]

On 11/10/2011 9:31 AM, Jerry Zhang wrote:


Unfortunately there is a difference between composition and
aggregation in my real word, and my application really care this
since it is trying to simulate this real world model, so my system
should track this difference accurately, otherwise the system may
not work well.

For example,
a. the Cls_arm and Cls_body may be composition, but not aggregation.
My app must ensure that " one arm instance only live with one body
instance, if the body instance die, the arm instance must die.


Create the arm as a private member '_arm' of body and make sure that no 
method of body passes out a reference to the arm. (In Python, outside 
code can still grab a reference to the private attribute, but that is a 
coding bug.)


I will point out that in the real world, dead donor transplants are 
based on the fact the parts of the body do NOT have to die when the 
composition does. I will not be surprised if we someday see arm transplants.


--
Terry Jan Reedy

--
http://mail.python.org/mailman/listinfo/python-list

Re: The python implementation of the "relationships between classes".

[Benjamin Kaplan]

On Thu, Nov 10, 2011 at 1:06 PM, Jerry Zhang  wrote:
>
>
> I just did an example code to describe what i am looking for.
> /**/
> # ...
>
> class Head:
>     def __init__(self):
>     self.size = 5
>
> class Hat:
>     def __init__(self):
>     self.color = red
>     def took_on(self, body):
>     self.body = body
>     def took_off(self, body):
>     del self.body
>
> class Body:
>     def __init__(self):
>     self.head = Head()
>     def take_on_hat(self, hat):
>     self.hat = hat
>     hat.take_on(self)
>     def take_off_hat(self):
>     hat.take_off(self)
>     del self.hat
>     def go_to_heaven(self):
>     take_off_hat(self)
>     del self.head
> /*--*/
>
> In this example, Head and body are COMPOSITION, which means
> a. A head only live with one body, it can not live with other body. It can
> not even live without body
> b. If the body go to die, the head also go to die.
>
> Body and Hat are aggregation, which means
> a. A hat live isolate with body, its life circle is isolate
> b. A hat only live with one body at a specific time, it can not live with
> two body(association would be more than one)
>
> So when the body die, the clean dead should include take_off Hat and del
> Head, otherwise, the code definition is not prciselly describing the
> relationship, which may cause a mess system, for example, a body has dead,
> but one hat is still associated with a unreferenced body.
> A point on this issue, maybe python is smart that the take_off_hat(self) is
> not needed in go_to_heaven() method(i am not sure yet), but the del
> self.head is sure needed, otherwise, we will have a no_body_head in our
> ZODB, that is extremely horrible, right?
>
> All of these points one, the four kinds of class relationship in UML
> precisely describe the real word, if the implementation is not precisely,
> you will have unexpected results.
> Of course, python may be smart to achieve such goal with less effort, that
> is why i am asking for a code example for all of the four relationships.

You're still misunderstanding Python's object model. del does NOT
delete an object. It deletes a name. The only way for an object to be
deleted is for it to be inaccessible (there are no references to it,
or there are no reachable references to it).
>>> foo = object()
>>> bar = foo
>>> foo

>>> bar

>>> del foo
>>> bar

>>> foo

Traceback (most recent call last):
  File "", line 1, in 
foo
NameError: name 'foo' is not defined


There is no way to force the go_to_heaven method to delete the head
unless you can make sure that all other references to the head are
weak references. If you need strictly-enforced relationships, Python
is probably not the right language for the job- you'll be better off
with C++ or Java.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The python implementation of the "relationships between classes".

[Jerry Zhang]

2011/11/11 Christian Heimes 

> Am 10.11.2011 17:09, schrieb Tim Wintle:
> >> Meanwhile, I have a ZODB running, which stores all the living
> >> objects.
> >
> > The ZODB is append only and stores all objects. Deleting references to
> > an object (which would causes deletion of standard python objects) won't
> > delete it from the zodb, it'll just delete the references.
>
> That's not entirely correct. In fact you *CAN* delete references to
> objects that are stored in ZODB. An unreferenced object is no longer
> accessible from future transactions. The object is only available from
> the transaction history log and thus still stored in the database file
> until the ZODB is packed. Once the ZODB is packed, all unreferenced
> objects are gone for good.
>
> ZODB is much more than a simple pickle jar. It's a transparent and
> poweful object database that behaves like an ordinary tree of Python
> objects.
>
>
I am verifying the ZODB solution, not clear yet, anyway, your points
regarding this sounds reasonable to me.
i am almost sure the python and ZODB designer has already did a good job to
make us handle such case easily, all i am trying to do is find the right
path.

Thanks a lot.


> --
> http://mail.python.org/mailman/listinfo/python-list
>
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The python implementation of the "relationships between classes".

[Jerry Zhang]

2011/11/11 Tim Wintle 

> On Thu, 2011-11-10 at 22:25 +0800, Jerry Zhang wrote:
> >
> >
> > 2011/11/10 Chris Angelico 
> > On Fri, Nov 11, 2011 at 12:58 AM, Jerry Zhang
> >  wrote:
> > > Cls_a:
> > > def __init__(self):
> > > self.at1 = 1
> > > Cls_b:
> > > def __init__(self):
> > > self.com1 = Cls_a()
> > > def __del__(self):
> > > del self.com1
> > > Is it a right implementation for composition?
> >
> >
> > Yes, except that you don't need to explicitly del it. Python
> > (at
> > least, CPython) is reference-counted; your Cls_b object owns a
> > reference to the Cls_a object, so (assuming nothing else has a
> > reference) that Cls_a will be happily cleaned up when the
> > Cls_b is.
> >
> > Python doesn't really talk about "composition" etc. It's much
> > simpler:
> > everything's an object, and you have references to that
> > object. A
> > named variable is a reference to some object. A member on an
> > object
> > is, too. Whenever an object is expired, all objects that it
> > references
> > lose one reference, and if that was the sole reference, those
> > objects
> > get expired too. It's a change of thinking, perhaps, but not a
> > difficult one in my opinion; and it's so easy to work with
> > when you
> > grok it.
> >
> >
> > Unfortunately there is a difference between composition and
> > aggregation in my real word, and my application really care this since
> > it is trying to simulate this real world model, so my system should
> > track this difference accurately, otherwise the system may not work
> > well.
>
> You might want to look into weak references:
> http://docs.python.org/library/weakref.html
>
> Although I agree with Chris that it sounds like your code might be
> easier with a change of perspective (I've not done much UML, but the way
> you're describing things sounds like a java-ish way of looking at it to
> me)
>
> > For example,
> > a. the Cls_arm and Cls_body may be composition, but not aggregation.
> > My app must ensure that " one arm instance only live with one body
> > instance, if the body instance die, the arm instance must die.
> >  b. the Cls_auto and the Cls_tyre may be aggregation. "One tyre still
> > can live even the auto is dead."
>
> That behaviour isn't really hard-coded as part of the language in
> python, as it's not required for memory management in the same way it
> would be in C++ or langauges without GCs.
>
> As long as no objects other than body objects hold a reference to arm
> objects then the arm object will be deleted.
>
> For The tyre object to be deleted when the auto object is deleted, there
> would have to be no references left to the tyre object. If there aren't
> any references then you can't know if it exists or not anyway, so the
> distinction isn't useful.
>

I just did an example code to describe what i am looking for.
/**/
# ...

class Head:
def __init__(self):
self.size = 5

class Hat:
def __init__(self):
self.color = red
def took_on(self, body):
self.body = body
def took_off(self, body):
del self.body

class Body:
def __init__(self):
self.head = Head()
def take_on_hat(self, hat):
self.hat = hat
hat.take_on(self)
def take_off_hat(self):
hat.take_off(self)
del self.hat
def go_to_heaven(self):
take_off_hat(self)
del self.head
/*--*/

In this example, Head and body are COMPOSITION, which means
a. A head only live with one body, it can not live with other body. It can
not even live without body
b. If the body go to die, the head also go to die.

Body and Hat are aggregation, which means
a. A hat live isolate with body, its life circle is isolate
b. A hat only live with one body at a specific time, it can not live with
two body(association would be more than one)

So when the body die, the clean dead should include take_off Hat and del
Head, otherwise, the code definition is not prciselly describing the
relationship, which may cause a mess system, for example, a body has dead,
but one hat is still associated with a unreferenced body.
A point on this issue, maybe python is smart that the take_off_hat(self) is
not needed in go_to_heaven() method(i am not sure yet), but the del
self.head is sure needed, otherwise, we will have a no_body_head in our
ZODB, that is extremely horrible, right?

All of these points one, the four kinds of class relationship in UML
precisely describe the real word, if the implementation is not precisely,
you will have unexpected results.
Of

Re: The python implementation of the "relationships between classes".

[Christian Heimes]

Am 10.11.2011 17:09, schrieb Tim Wintle:
>> Meanwhile, I have a ZODB running, which stores all the living
>> objects. 
> 
> The ZODB is append only and stores all objects. Deleting references to
> an object (which would causes deletion of standard python objects) won't
> delete it from the zodb, it'll just delete the references.

That's not entirely correct. In fact you *CAN* delete references to
objects that are stored in ZODB. An unreferenced object is no longer
accessible from future transactions. The object is only available from
the transaction history log and thus still stored in the database file
until the ZODB is packed. Once the ZODB is packed, all unreferenced
objects are gone for good.

ZODB is much more than a simple pickle jar. It's a transparent and
poweful object database that behaves like an ordinary tree of Python
objects.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The python implementation of the "relationships between classes".

[Tim Wintle]

On Thu, 2011-11-10 at 22:25 +0800, Jerry Zhang wrote:
> 
> 
> 2011/11/10 Chris Angelico 
> On Fri, Nov 11, 2011 at 12:58 AM, Jerry Zhang
>  wrote:
> > Cls_a:
> > def __init__(self):
> > self.at1 = 1
> > Cls_b:
> > def __init__(self):
> > self.com1 = Cls_a()
> > def __del__(self):
> > del self.com1
> > Is it a right implementation for composition?
> 
> 
> Yes, except that you don't need to explicitly del it. Python
> (at
> least, CPython) is reference-counted; your Cls_b object owns a
> reference to the Cls_a object, so (assuming nothing else has a
> reference) that Cls_a will be happily cleaned up when the
> Cls_b is.
> 
> Python doesn't really talk about "composition" etc. It's much
> simpler:
> everything's an object, and you have references to that
> object. A
> named variable is a reference to some object. A member on an
> object
> is, too. Whenever an object is expired, all objects that it
> references
> lose one reference, and if that was the sole reference, those
> objects
> get expired too. It's a change of thinking, perhaps, but not a
> difficult one in my opinion; and it's so easy to work with
> when you
> grok it.
> 
> 
> Unfortunately there is a difference between composition and
> aggregation in my real word, and my application really care this since
> it is trying to simulate this real world model, so my system should
> track this difference accurately, otherwise the system may not work
> well. 

You might want to look into weak references:
http://docs.python.org/library/weakref.html

Although I agree with Chris that it sounds like your code might be
easier with a change of perspective (I've not done much UML, but the way
you're describing things sounds like a java-ish way of looking at it to
me)

> For example, 
> a. the Cls_arm and Cls_body may be composition, but not aggregation.
> My app must ensure that " one arm instance only live with one body
> instance, if the body instance die, the arm instance must die.
>  b. the Cls_auto and the Cls_tyre may be aggregation. "One tyre still
> can live even the auto is dead."

That behaviour isn't really hard-coded as part of the language in
python, as it's not required for memory management in the same way it
would be in C++ or langauges without GCs.

As long as no objects other than body objects hold a reference to arm
objects then the arm object will be deleted.

For The tyre object to be deleted when the auto object is deleted, there
would have to be no references left to the tyre object. If there aren't
any references then you can't know if it exists or not anyway, so the
distinction isn't useful.

> Meanwhile, I have a ZODB running, which stores all the living
> objects. 

The ZODB is append only and stores all objects. Deleting references to
an object (which would causes deletion of standard python objects) won't
delete it from the zodb, it'll just delete the references.


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The python implementation of the "relationships between classes".

[Jerry Zhang]

2011/11/10 Jerry Zhang 

>
>
> 2011/11/10 Chris Angelico 
>
>> On Fri, Nov 11, 2011 at 12:58 AM, Jerry Zhang 
>> wrote:
>> > Cls_a:
>> > def __init__(self):
>> > self.at1 = 1
>> > Cls_b:
>> > def __init__(self):
>> > self.com1 = Cls_a()
>> > def __del__(self):
>> > del self.com1
>> > Is it a right implementation for composition?
>>
>> Yes, except that you don't need to explicitly del it. Python (at
>> least, CPython) is reference-counted; your Cls_b object owns a
>> reference to the Cls_a object, so (assuming nothing else has a
>> reference) that Cls_a will be happily cleaned up when the Cls_b is.
>>
>> Python doesn't really talk about "composition" etc. It's much simpler:
>> everything's an object, and you have references to that object. A
>> named variable is a reference to some object. A member on an object
>> is, too. Whenever an object is expired, all objects that it references
>> lose one reference, and if that was the sole reference, those objects
>> get expired too. It's a change of thinking, perhaps, but not a
>> difficult one in my opinion; and it's so easy to work with when you
>> grok it.
>>
>
> Unfortunately there is a difference between composition and aggregation in
> my real word, and my application really care this since it is trying to
> simulate this real world model, so my system should track this difference 
> accurately,
> otherwise the system may not work well.
>
> For example,
> a. the Cls_arm and Cls_body may be composition, but not aggregation. My
> app must ensure that " one arm instance only live with one body instance,
> if the body instance die, the arm instance must die.
>  b. the Cls_auto and the Cls_tyre may be aggregation. "One tyre still can
> live even the auto is dead."
>
> Meanwhile, I have a ZODB running, which stores all the living objects.
>
So lifecycle should be ensured by class definition. I originally thought
this topic would be talked somewhere since many python OOP designer should
have met this, or am i wrong on some point?


>
>
>> ChrisA
>> --
>> http://mail.python.org/mailman/listinfo/python-list
>>
>
>
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The python implementation of the "relationships between classes".

[Jerry Zhang]

2011/11/10 Chris Angelico 

> On Fri, Nov 11, 2011 at 12:58 AM, Jerry Zhang 
> wrote:
> > Cls_a:
> > def __init__(self):
> > self.at1 = 1
> > Cls_b:
> > def __init__(self):
> > self.com1 = Cls_a()
> > def __del__(self):
> > del self.com1
> > Is it a right implementation for composition?
>
> Yes, except that you don't need to explicitly del it. Python (at
> least, CPython) is reference-counted; your Cls_b object owns a
> reference to the Cls_a object, so (assuming nothing else has a
> reference) that Cls_a will be happily cleaned up when the Cls_b is.
>
> Python doesn't really talk about "composition" etc. It's much simpler:
> everything's an object, and you have references to that object. A
> named variable is a reference to some object. A member on an object
> is, too. Whenever an object is expired, all objects that it references
> lose one reference, and if that was the sole reference, those objects
> get expired too. It's a change of thinking, perhaps, but not a
> difficult one in my opinion; and it's so easy to work with when you
> grok it.
>

Unfortunately there is a difference between composition and aggregation in
my real word, and my application really care this since it is trying to
simulate this real world model, so my system should track this
difference accurately,
otherwise the system may not work well.

For example,
a. the Cls_arm and Cls_body may be composition, but not aggregation. My app
must ensure that " one arm instance only live with one body instance, if
the body instance die, the arm instance must die.
 b. the Cls_auto and the Cls_tyre may be aggregation. "One tyre still can
live even the auto is dead."

Meanwhile, I have a ZODB running, which stores all the living objects.



> ChrisA
> --
> http://mail.python.org/mailman/listinfo/python-list
>
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The python implementation of the "relationships between classes".

[Chris Angelico]

On Fri, Nov 11, 2011 at 12:58 AM, Jerry Zhang  wrote:
> Cls_a:
>     def __init__(self):
>         self.at1 = 1
> Cls_b:
>     def __init__(self):
>         self.com1 = Cls_a()
>     def __del__(self):
>         del self.com1
> Is it a right implementation for composition?

Yes, except that you don't need to explicitly del it. Python (at
least, CPython) is reference-counted; your Cls_b object owns a
reference to the Cls_a object, so (assuming nothing else has a
reference) that Cls_a will be happily cleaned up when the Cls_b is.

Python doesn't really talk about "composition" etc. It's much simpler:
everything's an object, and you have references to that object. A
named variable is a reference to some object. A member on an object
is, too. Whenever an object is expired, all objects that it references
lose one reference, and if that was the sole reference, those objects
get expired too. It's a change of thinking, perhaps, but not a
difficult one in my opinion; and it's so easy to work with when you
grok it.

ChrisA
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The python implementation of the "relationships between classes".

[Jerry Zhang]

Hi Chris,

Firstly thanks for your quick reply.

1. Your code example gives a point, but i may not reach my question yet,
maybe because i did not make myself understood yet. Here is a more detail
example question.

I have a classes sets described by UML, which could be refered as Cls_A,
Cls_B, CLs_C, Cls_D, Cls_E. There are four relationship between
them--dependency, association, aggregation, composition. What i need to do
is define all of the classes by python, and,of course, the class definition
should describe there relationship correctly.
For example, implement composition relationship between Cls_A and Cls_B,
which may means a instance of Cls_B is created and destroyed by a Cls_A
instance, My code may be like this(not sure since i am not quite familiar
with python yet):

Cls_a:
def __init__(self):
self.at1 = 1

Cls_b:
def __init__(self):
self.com1 = Cls_a()
def __del__(self):
del self.com1
Is it a right implementation for composition?

and i need also do other relationship definition into class, like
dependency, association, aggregation...

Is there any article or code example on the relationships implementation?


Thanks!
Biao


2011/11/10 Chris Angelico 

> On Fri, Nov 11, 2011 at 12:15 AM, Jerry Zhang 
> wrote:
> > For example, in composition model, the container object may be
> responsible
> > for the handling of embedded objects' lifecycle. What is the python
> pattern
> > of such implementation?
>
> Here's an example:
>
> class Test(object):
>  def __init__(self):
>self.lst=[1,2,3]
>self.map={"foo":12,"bar":34}
>
> This is a container that has a list and a dictionary in it. When an
> instance of the container is destroyed, its list and dictionary will
> be destroyed too (assuming nobody's made other references to them).
> You don't need to code anything explicitly for that.
>
> Chris Angelico
> --
> http://mail.python.org/mailman/listinfo/python-list
>
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The python implementation of the "relationships between classes".

[Chris Angelico]

On Fri, Nov 11, 2011 at 12:15 AM, Jerry Zhang  wrote:
> For example, in composition model, the container object may be responsible
> for the handling of embedded objects' lifecycle. What is the python pattern
> of such implementation?

Here's an example:

class Test(object):
  def __init__(self):
self.lst=[1,2,3]
self.map={"foo":12,"bar":34}

This is a container that has a list and a dictionary in it. When an
instance of the container is destroyed, its list and dictionary will
be destroyed too (assuming nobody's made other references to them).
You don't need to code anything explicitly for that.

Chris Angelico
-- 
http://mail.python.org/mailman/listinfo/python-list

The python implementation of the "relationships between classes".

[Jerry Zhang]

Greetings:

As you know, there are several kinds of relationships between classes in
the UML -- dependency, association, aggregation, composition.
Q1. Is there any article or code example on its implementation in python?
Q2. For example, in composition model, the container object may be
responsible for the handling of embedded objects' lifecycle. What is the
python pattern of such implementation?
would it be adding __del__ to the container class to del embedded objects
or something else?

Thanks!
Biao
-- 
http://mail.python.org/mailman/listinfo/python-list