develooper Front page | perl.perl5.porters | Postings from March 2011

Re: Revising Perl's OO docs - a new OO tutorial

Thread Previous | Thread Next
Dave Rolsky
March 5, 2011 13:11
Re: Revising Perl's OO docs - a new OO tutorial
Message ID:
On Sat, 5 Mar 2011, brian d foy wrote:

> People might want Moose to be a best practice, and people who write
> documentation may wish it were so, but that doesn't allow any of us to
> skip the careful analysis and deep thought it should take to elevate it
> to an actual best practice. Why are so many past best practices out of
> favor now? No one relly thought about both sides of the issue, and no
> one required anyone else to be intellectually rigorous and honst about
> it.

FWIW, the tutorial I wrote does not say anything like "using Moose is a 
best practice. It does say:

   We strongly recommend that you use one of these systems. Even the most
   minimal of them eliminates a lot of repetitive boilerplate. There's
   really no good reason to write your classes from scratch in Perl.

The phrase "one of these" is meant to mean any object framework. This 
paragraph comes before introducing the three specific object frameworks 
that I cover.

The Moose section highlights several of Moose's features and then says "Of 
course, C<Moose> isn't perfect." After that, I mostly talk about the 
compile time speed hit and the fact that it has more deps than the other 
two systems I cover. I _do_ say:

   Before you panic, know that many people do use C<Moose> for
   command-line tools and other startup-sensitive code. We encourage you
   to try C<Moose> out first before worrying about startup speed.

The conclusion is:

   As we said before, Perl's minimal OO system has lead to a flourishing
   of OO systems on CPAN. While you can still drop down to the bare metal
   and write your classes by hand, there's really no reason to do that in

   We encourage you to play with and evaluate L<Moose>,
   L<Class::Accessor>, and L<Object::Tiny> to see which OO system is right
   for you.

So I hardly thing this document says anything like "Moose is a best 
practice". I'd be fine with any or all of:

- adding more caveats about Moose, Class::Accessor, or Object::Tiny
- mentioning other systems in the conclusion, or just mentioning that many 
other options exist
- some waffling near the end about how nothing's set in stone, things 
change, blah de blah blah, as long as it's near the end.


Your guide to all that's veg      House Absolute(ly Pointless)

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About