{
    package Cat;

    use Moose;

    has 'name', is => 'ro', isa => 'Str';
    has 'age',  is => 'ro', isa => 'Int';
    has 'diet', is => 'rw';
}

... than the corresponding code where you must write your own accessors, poke into a blessed hash directly (and bless it yourself), perform your own coercions and verifications, and the like.

Of course, the preferred syntax for doing this within the Moose documentation is different from how I've done things. Moose recommends:

{
    package Cat;

    use Moose;

    has 'name' => (is => 'ro', isa => 'Str');
    has 'age' =>  (is => 'ro', isa => 'Int');
    has 'diet' => (is => 'rw');
}

Sometimes you quote the name of the attribute and sometimes you don't.

Should I drop the parentheses? Should I drop the fat arrow between the name of the attribute and its specializers? I do in my own Moose code for my preferences, and I did in the book. Then I thought about it and realized why I write code this way.

First, a digression. Perrin Harkins mentioned the inability of the "Takes a block!" prototype to replicate builtin syntaxes as a reason to dislike syntax-bending modules such as Error. For example:

use Error ':try';

try
{
    ...
}
catch
{
    ...
};

... really needs that trailing semicolon. For similar reasons, many modules which use Devel::Declare magic go through contortions to add trailing commas and semicolons. Perl 5's syntax is malleable, but when the parser wants something from the lexer, it really really wants something from the lexer. (When it wants to know that a statement or a group of terms has ended, you don't get to lie.)

In other words, even though you have a lot of options for mangling Perl 5's syntax any way you like it, the semantics of the host language will shine through. A parenthesis is a parenthesis. A labeled block is a labeled block. A bare sub { ... } is never an expression on its own, and it can never terminate an outer expression.

This is one of the downfalls of the so-called "embedded domain specific languages". If you haven't written your own parser, you'll have to take what you can get. This is even true if you do write a parser and generate and eval code, and it's especially true if your EDSL desugars to chained function or method calls.

I'm not suggesting a flaw with Moose's approach: it's clever and Perlish and doesn't succumb to the saccharine cutery of so many other so-called DSLs. (To my knowledge, no one in the Moose world has claimed it's anything other than Perl 5 syntax bent slightly into something which looks declarative enough.)

My concern—especially when explaining object orientation in Perl 5 to novices—is that any extra syntactic elements might confuse people to think that they mean more than they mean. You and I might both understand that the grouping parentheses in the Cat attribute declaration are merely visual hints to the reader that the specializers are subordinate to the attribute itself and that the fat arrow between the name of the attribute and its grouped specializers confers the notion of pairing between the attribute and its specializers, but how do you explain that to someone who's still struggling to figure out what this encapsulation thing is all about?

I've attempted caution throughout the book such that the fat comma always signifies a pairish relationship, such as for hash keys or named arguments. Certainly you can always use it in place of the skinny comma (and, barring any quoting changes, vice versa), but is it clear to do so?

Likewise, you can wrap parentheses around almost any old rvalue (barring precedence changes) and not change the behavior of lists, yet this confuses novices all the time:

my @lololol = ( 1, 2, ( 3, 4, (5, 6) ) );

I'm not criticizing the Moose documentation or the standard approaches to formatting Moose code. I'm not suggesting a change. I don't like deviating from community standards for declaring Moose attributes. Even so, avoiding the need to explain the equivalencies of syntax to people for whom learning syntax is still a really big deal is itself to me a big deal.

I alluded to this question when I asked should the Modern Perl book prefer cpanminus?. I've tried to explain my goal a couple of times in private, but I've never done so systematically, and I've never invited wide discussion.

I'm trying to figure out the right audience for the Modern Perl book in preparation for publishing this summer. My initial idea to write the book came from two places.

First, the Camel book is a decade old, and there'll never be a new edition which covers Perl 5. Despite the fact that fourteen (almost fifteen) stable releases of Perl 5 have come out since then (and at least four of them, possibly five) count as major, the canonical printed language reference is out of date and, at this point, all but abandoned.

Second, the best explanation of JavaScript I've ever encountered is JavaScript: The Good Parts. Like almost any other language, JavaScript has some good ideas, some poor implementations of good ideas, and some bizarre ideas that you shouldn't ever use. In 176 pages, Crockford explains how the language works and how its pieces fit together. Without covering everything, you can go from knowing how to dabble with it to writing good code.

Yet you're not an expert. You understand enough of the theoretical underpinnings of the language and the practical issues of using it to be productive, to use it to its advantages, and how to avoid or at least work around misfeatures.

I want to do something similar for Perl 5. I believe that understanding how to use perldoc is essential to programming Perl well, as is understanding the two forms of context and how they influence other code, as is understanding Perl's operator-oriented container-based type system.

I believe it's possible to explain how Perl 5 works in a couple of hundred pages, such that someone who's worked through a tutorial or two on setting up a Perl development environment and written something more than "Hello, world!" can understand Perl and continue to learn and to become productive. If you add in permission to experiment with small snippets of code, there are few limits as to where readers can go.

In short, I want to produce a book you can hand to someone who says "Perl? Oh, I've played around with it a bit." and tell them "Once you've read and understood this, you'll understand Perl."

I think I can do that without also bearing the burden of teaching people how to program in general. I assume that pointing interested novices to tutorials to set up Strawberry Perl and/or Padre is sufficient explanation for the basic material.

What do you think?