object vs class oriented -- xotcl

Discussion in 'Python' started by William Pursell, Jan 24, 2008.

  1. 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?
     
    William Pursell, Jan 24, 2008
    #1
    1. Advertising

  2. On Jan 24, 12:35 pm, William Pursell <> 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
     
    Jonathan Gardner, Jan 24, 2008
    #2
    1. Advertising

  3. 2008/1/24, 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?
    > --
    > http://mail.python.org/mailman/listinfo/python-list
    >


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

    a = A()
    a.__class__ = B

    That ? Maybe you meant something else.

    --
    -- Guilherme H. Polo Goncalves
     
    Guilherme Polo, Jan 24, 2008
    #3
  4. 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
     
    Steven D'Aprano, Jan 24, 2008
    #4
  5. 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.
     
    Bruno Desthuilliers, Jan 25, 2008
    #5
  6. On Jan 24, 9:16 pm, "Guilherme Polo" <> wrote:
    > 2008/1/24, William Pursell <>:
    > <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.
     
    William Pursell, Jan 29, 2008
    #6
  7. En Tue, 29 Jan 2008 16:22:24 -0200, William Pursell
    <> 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
     
    Gabriel Genellina, Jan 29, 2008
    #7
  8. William Pursell

    Guest

    On 29 Jan., 19:22, William Pursell <> 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-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
     
    , Feb 1, 2008
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Robert Hathaway
    Replies:
    0
    Views:
    420
    Robert Hathaway
    Jul 29, 2003
  2. Robert Hathaway
    Replies:
    0
    Views:
    422
    Robert Hathaway
    Jul 29, 2003
  3. Robert Hathaway
    Replies:
    1
    Views:
    459
    Robert J Hathaway III
    Jul 29, 2003
  4. Replies:
    2
    Views:
    429
    Bruno Desthuilliers
    May 26, 2008
  5. rolo
    Replies:
    3
    Views:
    174
    Robert Klemme
    Apr 9, 2004
Loading...

Share This Page