Traits, rôles and other repurposed terms

[Ovid]

--- Jonathan Stowe <jns at gellyfish.com> wrote:

> Having realized this and now I'm not struggling to find some meaning
> in the terms themselves it all becomes much clearer. 
> 
> I'd still like a nice self-sufficient paragraph that explains the
> ideas without reference to some example code though.

I'll take a swing at this.

In OO programming, many of us get the manager/programmer example. 
Should they be subclasses of "employee"?  No, because an employee might
very well fill both roles.

(And that's why the term "roles" is a better term than "traits".)

So what happens is that you have an employee object which can implement
at either compile time or run time the "programmer" and/or "manager"
roles.

The other benefit of "roles" is that both an programmer and a manager
might be able to "dawdle", but an employee might do this by reading the
articles on programming.reddit.com and the manager might do it be
commenting on programming.reddit.com (*cough*).  When you ask an
employee to dawdle, how they dawdle depends on the context in which
you're asking them.

I'm not claiming that this is an easy thing to really understand, but
it's the cleanest way I've encountered of solving hard compositional
problems.

Cheers,
Ovid

--
Buy the book  - http://www.oreilly.com/catalog/perlhks/
Perl and CGI  - http://users.easystreet.com/ovid/cgi_course/
Personal blog - http://publius-ovidius.livejournal.com/
Tech blog     - http://use.perl.org/~Ovid/journal/