object vs class oriented -- xotcl

[William Pursell]

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.tcl.tk/1297)

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?

 

[Jonathan Gardner]

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.
.... def foo(self): print "Foo.foo"
........ def foo(self): print "Bar.foo"
....Bar.foo

 

[Guilherme Polo]

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.tcl.tk/1297)

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?

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

a = A()
a.__class__ = B

That ? Maybe you meant something else.

 

[Steven D'Aprano]

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:
.... def whatami(self):
.... return "I am a delicious and tasty processed meat product"
........ def whatami(self):
.... return "I am a colourful bird with a large vocabulary"
....'I am a colourful bird with a large vocabulary'


If you actually play around with this, you'll soon find the limitations.
For instance:
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: __class__ assignment: only for heap types

 

[Bruno Desthuilliers]

Steven D'Aprano a écrit :

Yes, mostly. Example:
(snip)

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

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]

2008/1/24, William Pursell <[email protected]>:
<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]

En Tue, 29 Jan 2008 16:22:24 -0200, William Pursell

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.

 

[neumann]

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-objpattern.pdf)

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-mixin.pdf)

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