Robert Klemme wrote:

> I missed the term "role" in your explanation.  Cause that's the way I had
> described this: the person changes her roles over time.  Changing the
> class is certainly an option here although in this example you would
> likely want to restrict classes to sub classes of Person.
> 
> But what do you do if the Person needs to play several roles at a time?
> Change the class for each method invocation?  That's likely going to be
> inefficient - and considering multiple threads it restricts concurrency
> dramatically.
> 
> In Ruby the ideal way IMHO would be to have the reverse method of #extend
> so if an instance takes on a role it uses a special mixin module's methods
> and un-mixes this module when it leaves the role. 

I am thinking along the same lines as Robert here T. I don't see why you 
would want to change the class of an object to become something else, it 
seems if that comes up their was a flaw in the design of the Person class.

Thinking intuitively on this if you had a person who was a Construction 
worker and became a fireman, would you really remove the persons' 
ability to be a construction worker to be a fireman? I'd say no. The 
person will still know how to build things, you're just extending what 
they know how to do or their *role* as Robert put it. There's no need to 
add extra work and start swapping baseclasses.

Zach