|The stupid question is the question not asked|
|( #3333=superdoc: print w/replies, xml )||Need Help??|
Isn't the main point about patterns a kind of contract with both parties hopefully understanding the meme in question identically? To allow selecting one approach as the default approach? To allow common/default assumptions?
To allow reuse and communication with neither
So a team selecting a set of patterns to allow for default assumptions is a good thing (e.g. about large scale architecture, constraints, preferred approaches). Actually improving team (or CPAN author / module user) communication.
A herd of small patterns all slightly different?
Way too much of a good thing (cf. the missing default OO style for Perl5). So skimming a book introducing yet another set of patterns is good to obtain new tricks and approaches. But being a dictionary, such a book only offers a little help with the real problem: communication. And with Perl's expressivity (plus), many of the low-level acclaimed C++ patterns boil down to more or less single-line techniques (e.g. Schwartzian transform). Or lack direct applicability as we still didn't select a default OO style (minus - it's not helpful if a trivial one-line pattern requires 20 lines of interface glue to cope with both blessed hashes and blessed scalars).
Now what is the set of patterns and assumptions that are safe to be assumed default/standard for random CPAN module ABC?
Is selecting/migrating such defaults for OO or just CPAN modules only possible with a Revolution once in a while, with breakage of a scope similar to the Perl5-to-Perl6 situation?
not really convinced about the most of the wave of pattern books (read: small-scale pattern dictionaries),
In reply to Re^3: Questions from "Coders at Work"