Replace Whole Object Through Object Method

[Bruno Desthuilliers]

Maric Michaud wrote:
> Le lundi 26 juin 2006 22:37, digitalorganics at gmail.com a écrit :
> 
>>Won't work because there will be employers that aren't workers.
>>And yes, only some workers will become employers, but also only some
>>employers will also be workers (at some point in program). Let me be
>>more clear:
>>
>>workers
>>--> subset of workers --become--> employers
>>employers
>>--> subset of employers --become--> workers
>>
>>It is very important that both should maintain attribute values,
>>regardless of whether they take on new "roles". Furthermore, this is a
>>very simple case and ultimately in my program an object should be able
>>to dynamically take on a multitude of roles (classes of behavior)
>>without mucking at all with their pre-existing states.
> 
> 
> This seem to be a OO design problem

Obviously.

> and you clearly make a misuse of 
> inheritance,

Chapter and verse, please ?
s/misuse/creative use/

> if a person can eventually have many roles, but doesn't have 
> this role for all his lifetime, then the person *is* not his roles.

And ? In a dynamically typed language, inheritance is about
implementation, not subtyping. The class of an object is nothing more
than an attribute, and as such is not necessarily fixed for the lifetime
of the object.

> That the meaning of inheritance, class B(A) means a B is a A.
> The association between a person and his roles is obviously a 1-n association, 
> which can be rendered by different patterns (delegation, composition, 
> strategy, etc.).

You've learned your lessons well. That's fine. Now please understand
that there's a huge difference between the book (usually based on static
some static language) and dynamic OOPLs. IOW : free your mind.

In Python, you can dynamically change the class of an object at runtime.
And the attribute lookup rule is to first lookup the object, then the
class (which is itself an object FWIW). So you can see the object/class
relationship as a somewhat specialised composition/delegation
relationship. In fact, in Python, a class is both an object factory and
delegatee.

> You should google on "design patterns" and make your choice.

FWIW, a good part of the canonical design patterns are mostly workaround
the lack of flexibility in languages like C++ and Java. The Strategy
pattern's simplest Python implementation is to dynamically replace a
method on a per-object basis. The State pattern's simplest
implementation in Python is to dynamically change the class of an object.

Of course, one of the canonical solutions to the OP's problem is to use
composition/delegation. But doing it the canonical way would imply
creating instances of the role objects and passing them the instance as
param so they can access it's attributes. It works, but it creates a
cyclic dependancy between the object and it's roles, so you would have
to use weakrefs. Dynamically creating new classes with the appropriate
bases and assigning them to the object's __class__ attribute is another
way to achieve the same result, and it's perfectly legal.

Now I do agree that it can become tricky to manage correctly wrt/ mro
rules !-)



-- 
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb at xiludom.gro'.split('@')])"