Traits, rôles and other repurposed terms

[Andy Wardley]

Jeff Anderson wrote:
 > I don't know ... maybe i am just more interested in getting stuff done
 > for $manager instead of building complex architectures

Remember that Catalyst isn't just getting stuff done for $manager. It's
getting @stuff done for @people with @managers for @years.

Writing any kind of generic, reusable software for @other_people to use is an
order of magnitude[1] harder than writing software to solve a specific
problem. You have to consider the multitude of different ways in which people
will want to use (and misuse) the software, not to mention to variety of other
Perl modules they'll want to use it with (half of which will be NFG[2]).

Writing a generic plugin mechanism for any kind of generic software is an
order of magnitude harder than just writing the generic software in the first
place. It's a whole new set of thorny issues bolted onto the side of the first
set of problems. It's triple-hard in Perl because there's more than one way to
do everything, and at least two of those ways will be mutually incompatible.

 > I just don't buy that stuff like roles
 > are actually going to make my job easier.

Probably not.

When writing "one-off" software you can generally avoid compositional
conflicts by choosing an underlying architecture/style/object layout/class
hierarchy/etc that suits the project and sticking with it. You'll probably
have little more to worry about[3] than choosing suitable names for modules,
methods, variables, etc., making sure that they don't clash and all Play
Nicely[tm] with each other.

But as soon as you give someone the opportunity to plug your module(s) in
theirs or theirs into yours, then there's a much greater chance of two bits of
code conflicting in some unforeseen way. These are the kind of problems that
more advanced compositional features like roles and traits are particularly
useful for.

 > I getting pretty sick and tired of OO.

Yep, I think we're all bored of OO-as-hype.

I'm not defending roles & traits, OO, Catalyst or Jonathan in particular.
I'm just highlighting the fact that writing a generic software product (like
Catalyst) for other people to use throws up a whole new set of problems
that you don't get writing a specific single-use application.  So although
I'm not snacking on them myself, I can appreciate why roles and traits are
the cheese-on-toast that is assuaging JR's hunger.

A

[1] Within an order of magnitude or two
[2] Not Functioning Goodly
[3] In terms of architecture... obviously you still need to worry about all
     the other functionality of your software.