Damian Conway wrote:
Darren Duncan wrote:
pg 36 - About the "Perl Best Practices" book, you should be clear to
mention that what is considered best practices has evolved significantly
since that book came out, so teams can't simply agree on "We'll just follow
PBP guidelines" and call it a day, but should study more modern resources
While it's certainly true that best practices have evolved (and
modernized ;-) since PBP came out, teams *can* still simply agree to
follow PBP. They won't we as well off as if they'd thought about the
issues themselves (i.e. read and followed the advice in Chapter 1) and
explored the various modern/evolved resources now available, but they'd
still be much better off than they are at present.
Not everyone has the time, inclination, or capacity to evaluate
the myriad possibilities and make informed personal judgements in
Ideally, if you mention PBP, describe it as a starting point (which is
how it describes itself in Chapter 1, btw), and the various Enlightened
and Modern Perl movements as evolutionary resources for going much
further in certain very specific directions.
Well, the slideshow could also be left as it is and my comment about PBP
disregarded; it also works fine as is; it might be that mentioning
somewhat-outdated is just pointing out the obvious, or alternately that doing so
might confuse people, and those who actually read the book would see that
Chapter 1 says how to interpret it anyway.
So another proposal I have is to add to the slideshow mentions of the
Enlightened and Modern Perl movements and where one can go to read more, this
being supplemental to PBP.
in particular the recommendation to use Class::STD/etc is outdated,
and people should use Moose instead.
There is no doubt that Moose is an excellent and very advanced framework,
but both the above assertions are highly debatable, especially if you
s/moribund Class::Std/actively developed Object::InsideOut/.
My own opinion is that the modern best way to use inside-out objects is in
combination with Moose, as the physical representation used for objects behind
the scenes, rather than each user class having direct package lexicals like
%foo_attr and %bar_attr. But this matter isn't really about Tim's talk so I
won't discuss inside-out/etc further here.
-- Darren Duncan