[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.python

object vs class oriented -- xotcl

William Pursell

1/24/2008 8:36:00 PM


I've been away from Python for at least a year, and in the interim
have spent a little time looking at the XOTcl object framework for
Tcl. One of the interesting features of XOTcl is the ability for an
object to change class dynamically. The XOtcl documentation makes the
claim that this makes it object oriented, while most other languages
are "class oriented". Here's a snippet from the wiki, from a post to
the mailing list by Gustaf Neumann: (http://wiki.t...)

Class-oriented means: look at the class and you know exactly how all
of the instances look alike. The class is the first and primary
language construct; the class is well the place where you specify the
instance variables (there are no instance variables except those
specified in the class). The only kind of individualism left in the
objects is to let them differ by their state (the values of their
instance variables). Changing classes (class migration) is
conceptually quite hard for this setup.

Object-oriented (in this distinction) means that the primary elements
are objects, which keep all instance variables. classes my be used to
specify the behavior of objects, they are container for methods and
they control the life-cycle of objects. Objects are like the facts,
and classes are like rules, that determine the behavior of the
objects. Since the connection between objects and classes is rather
loose, it is sufficient to define their relation through an
association. Therefore it is quite easy to change the relation between
objects and classes (and between classes and classes) dynamically.
Objects have arbitrary individualism, they may have variables never
used in any class, they may have private procs etc.

I'm not sure that describes the method well. Basically, you can
instantiate an object A of class Foo, and later change A to be an
object of class Bar. Does Python support this type of flexibility?
As I stated above, I've been away from Python for awhile now, and am a
bit rusty, but it seems that slots or "new style" objects might
provide this type of behavior. The ability to have an object change
class is certainly (to me) a novel idea. Can I do it in Python?
7 Answers

Jonathan Gardner

1/24/2008 9:14:00 PM

0

On Jan 24, 12:35 pm, William Pursell <bill.purs...@gmail.com> wrote:
> I'm not sure that describes the method well. Basically, you can
> instantiate an object A of class Foo, and later change A to be an
> object of class Bar. Does Python support this type of flexibility?
> As I stated above, I've been away from Python for awhile now, and am a
> bit rusty, but it seems that slots or "new style" objects might
> provide this type of behavior. The ability to have an object change
> class is certainly (to me) a novel idea. Can I do it in Python?

Short answer: yes, easily.

Long answer: observe.

>>> class Foo(object):
.... def foo(self): print "Foo.foo"
....
>>> class Bar(object):
.... def foo(self): print "Bar.foo"
....
>>> a = Foo()
>>> a.__class__ = Bar
>>> a.foo()
Bar.foo

Guilherme Polo

1/24/2008 9:17:00 PM

0

2008/1/24, William Pursell <bill.pursell@gmail.com>:
>
> I've been away from Python for at least a year, and in the interim
> have spent a little time looking at the XOTcl object framework for
> Tcl. One of the interesting features of XOTcl is the ability for an
> object to change class dynamically. The XOtcl documentation makes the
> claim that this makes it object oriented, while most other languages
> are "class oriented". Here's a snippet from the wiki, from a post to
> the mailing list by Gustaf Neumann: (http://wiki.t...)
>
> Class-oriented means: look at the class and you know exactly how all
> of the instances look alike. The class is the first and primary
> language construct; the class is well the place where you specify the
> instance variables (there are no instance variables except those
> specified in the class). The only kind of individualism left in the
> objects is to let them differ by their state (the values of their
> instance variables). Changing classes (class migration) is
> conceptually quite hard for this setup.
>
> Object-oriented (in this distinction) means that the primary elements
> are objects, which keep all instance variables. classes my be used to
> specify the behavior of objects, they are container for methods and
> they control the life-cycle of objects. Objects are like the facts,
> and classes are like rules, that determine the behavior of the
> objects. Since the connection between objects and classes is rather
> loose, it is sufficient to define their relation through an
> association. Therefore it is quite easy to change the relation between
> objects and classes (and between classes and classes) dynamically.
> Objects have arbitrary individualism, they may have variables never
> used in any class, they may have private procs etc.
>
> I'm not sure that describes the method well. Basically, you can
> instantiate an object A of class Foo, and later change A to be an
> object of class Bar. Does Python support this type of flexibility?
> As I stated above, I've been away from Python for awhile now, and am a
> bit rusty, but it seems that slots or "new style" objects might
> provide this type of behavior. The ability to have an object change
> class is certainly (to me) a novel idea. Can I do it in Python?
> --
> http://mail.python.org/mailman/listinfo/p...
>

class A(object): pass
class B(object): pass

a = A()
a.__class__ = B

That ? Maybe you meant something else.

--
-- Guilherme H. Polo Goncalves

Steven D'Aprano

1/24/2008 9:28:00 PM

0

On Thu, 24 Jan 2008 12:35:44 -0800, William Pursell wrote:

> Basically, you can
> instantiate an object A of class Foo, and later change A to be an object
> of class Bar. Does Python support this type of flexibility? As I
> stated above, I've been away from Python for awhile now, and am a bit
> rusty, but it seems that slots or "new style" objects might provide
> this type of behavior.

If you think slots are a candidate for this functionality, I think you
have misunderstood what slots actually are. Slots don't define what class
the object has, they are a memory optimization for when you need vast
numbers of instances and don't need arbitrary attributes.


> The ability to have an object change class is
> certainly (to me) a novel idea. Can I do it in Python?

Yes, mostly. Example:

>>> class Spam(object):
.... def whatami(self):
.... return "I am a delicious and tasty processed meat product"
....
>>> class Parrot(object):
.... def whatami(self):
.... return "I am a colourful bird with a large vocabulary"
....
>>>
>>> s = Spam()
>>> s.whatami()
'I am a delicious and tasty processed meat product'
>>> s.__class__ = Parrot
>>> s.whatami()
'I am a colourful bird with a large vocabulary'


If you actually play around with this, you'll soon find the limitations.
For instance:

>>> s.__class__ = int
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: __class__ assignment: only for heap types




--
Steven

Bruno Desthuilliers

1/25/2008 12:56:00 PM

0

Steven D'Aprano a écrit :
> On Thu, 24 Jan 2008 12:35:44 -0800, William Pursell wrote:
>
>> The ability to have an object change class is
>> certainly (to me) a novel idea. Can I do it in Python?
>
> Yes, mostly. Example:
>
(snip)
>
> If you actually play around with this, you'll soon find the limitations.
> For instance:
>
>>>> s.__class__ = int
> Traceback (most recent call last):
> File "<stdin>", line 1, in <module>
> TypeError: __class__ assignment: only for heap types
>

Other limitations may appear with frameworks relying on metaprogramming
features for their inner working so users don't have to worry about
boilerplate - something you'll often find in recent web frameworks, orms
etc...

Mostly, the point with dynamically changing the class of an object
(whether or not your in the above situation) is that you must ensure
consistant state by yourself, which sometimes happens to be far less
trivial than it seems at first look. I once tried to implement the State
pattern this way (in real-life code), and while it worked, it ended
being more complicated (and brittle) than implementing it the canonical
way. So while it *may* be a good solution, I'd advise you to carefully
check the concrete use case before using this feature.

William Pursell

1/29/2008 6:22:00 PM

0

On Jan 24, 9:16 pm, "Guilherme Polo" <ggp...@gmail.com> wrote:
> 2008/1/24, William Pursell <bill.purs...@gmail.com>:
> <referring to changing an objects class>
> Can I do it in Python?
>
>
> class A(object): pass
> class B(object): pass
>
> a = A()
> a.__class__ = B
>
> That ? Maybe you meant something else.

That is what I was referring to, but it isn't the core
functionality that I'm after. (My bad for a poor
description.)

I'm fairly excited at the idea of being able to
do per-object mixins in xotcl. I guess it would
look like this in python:

BROKEN CODE:
a = object()
a.__class__.append( foo )
a.__class__.append( bar )

In python, if you want an object to me a member
of 2 classes, it seems that you have no choice but
to declare a new class that inherits from both. eg:

class foobar( foo, bar):
pass
a = foobar()

Is it possible to make an object be a member
of 2 classes without defining such a class? I
believe "per object mixin" is the correct
term for such an animal. The first several google
hits on that phrase all reference xotcl, so I'm
not sure if that is an xotcl inspired vocabulary
that isn't really standard.

Gabriel Genellina

1/29/2008 11:06:00 PM

0

En Tue, 29 Jan 2008 16:22:24 -0200, William Pursell
<bill.pursell@gmail.com> escribi�:

> I'm fairly excited at the idea of being able to
> do per-object mixins in xotcl. I guess it would
> look like this in python:
>
> BROKEN CODE:
> a = object()
> a.__class__.append( foo )
> a.__class__.append( bar )
>
> In python, if you want an object to me a member
> of 2 classes, it seems that you have no choice but
> to declare a new class that inherits from both. eg:
>
> class foobar( foo, bar):
> pass
> a = foobar()
>
> Is it possible to make an object be a member
> of 2 classes without defining such a class? I
> believe "per object mixin" is the correct
> term for such an animal. The first several google
> hits on that phrase all reference xotcl, so I'm
> not sure if that is an xotcl inspired vocabulary
> that isn't really standard.

No, an instance can be of only one class at a time. But you can generate
dynamically the foobar class:
foobar = type("foobar", (foo,bar), {})
and provided `a` is an instance of any other user defined class (not bare
object), this works:
a.__class__ = foobar
Or simply a = foobar()

If you are going to use this heavily, I suggest a "class cache" in order
to avoid creating as many classes.

--
Gabriel Genellina

neumann

2/1/2008 12:01:00 AM

0

On 29 Jan., 19:22, William Pursell <bill.purs...@gmail.com> wrote:
> I
> believe "per object mixin" is the correct
> term for such an animal. The first several google
> hits on that phrase all reference xotcl, so I'm
> not sure if that is an xotcl inspired vocabulary
> that isn't really standard.

well, it depends, what you mean by "standard" when it comes
to mixins. We coined the term to distinguish between per
object and per class mixins, where the per objects mixins
have much in common with the decorator design pattern (see
e.g. http://nm.wu-wien.ac.at/research/publications/xotcl-objp...)

We have as well a paper showing that the approach based on
intersection
classes does not scale well, especially when multiple supplemental
classes should be mixed in, and some of the behavior should be as well
mixed out (see e.g. section 3.3 in http://nm.wu-wien.ac.at/research/publications/xotcl...)

If you are interested in the matter, we have as well a recent paper
http://nm.wu-wien.ac.at/research/publication... providing
declarative semantics for mixins, and there is many more related
papers in the publications section of media.wu-wien.ac.at