Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

jplindstrom (594)

jplindstrom
  (email not shown publicly)

Journal of jplindstrom (594)

Monday July 07, 2008
07:21 PM

Moose lessons

[ #36867 ]

Things I've learned by Moosifying classes over the past few days. In no particular order.

Moose is cool.

But it's too easy to go overboard and try to use all of it at once.

Type constraints are very useful, if nothing else because of the documentation value, e.g.

has 'rex_skip_source_file' => (
    is => 'rw',
    isa => 'ArrayRef[RegexpRef]',
    default => sub { [] },
);
 
has is_publication_outlet => (is => "rw", isa => "Int");

The default of ''is => "ro"'' seems badly chosen. Having ''is => "rw"'' everywhere seriously adds clutter. From what I gather it's from Perl 6, and the little Perl 6 code I've seen leaves the same impression. I guess the argument is "public accessors are bad so it should hurt to use them". But that argument doesn't hold water, because this is also how you declare private attributes. So either way, most of your attribute declarations will have "rw". Not very optimized for the common case.

Type constraints are also useful because you can do certain things declaratively instead of imperatively. Data driven code is always a win; less code ==> less bugs, so refactor it into the framework or language.

The Perl internal types are documented, but not in an obvious place.

Many attributes in a compact layout become visually disturbing. Aligning things here is a must for readability. Apparently Vim has some kind of magic I'm envious of. A very simple split-on-non-string-whitespace-and-render-in-columns would work here.

Bool seems weird and doesn't play well with Perl's idea of true / false.

The constraints above disallow undef, so if you want a value to be either a string or undef, the syntax is:

isa => "Maybe[Str]"

To override the default for an attribute in a subclass without having to retype the entire declaration you prepend a plus:

has "+is_persistable" => (default => 1);

This visual distinction feels very right and makes it obvious it is overridden.

Roles are nice but the keywod "with MyRole" isn't the same as Perl 6' "does MyRole". I'm not sure which is better for guiding the thought on how roles should be named, but they will have different outcomes if you care about naming at all.

The "lazy => 1" property on attributes is very cool and all you need to decompose bulky initialization code into a roll-your-own IoC setup for an object.

Moose is clearly the new default way of Perl OOP.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Many attributes in a compact layout become visually disturbing. Aligning things here is a must for readability. Apparently Vim has some kind of magic I'm envious of.

    No, that's just applying my default .perltidyrc.

  • First off, thanks for the nice review, it is good to get feedback from new Moose users. The #moose echo chamber on IRC is obviously not so helpful in this regard.

    The default of ''is => "ro"' is badly chosen ...

    Actually the default is to not create any accessors at all. While it might seem useless, it is a perfectly valid use case, take this example for instance:

    has 'some_flag' => (
        predicate => 'is_some_flag_set'
    );

    This will create a predicate method for checking if the flag is

    • Regarding "docs". Do you know of a book that may be in the works? It seems to me that Moose is such a good thing for Perl OO that it would be a good thing to have a book out there as well.

    • It differs from Perl in that it wont accept an arbitrary value and treat it as true.

      That was what I was referring to. Maybe if it's advertised as these-are-the-Perl-types kind of type constraint it should actually conform to the Perl true/false idea, and if you want to stricten it up to only support 1/0/undef you use a different one (Bool vs Boolean) ?

      Anyway, it surprised me when using it, that's all.

      /J

      • I think perhaps you are mistaking a "value" for the "value of an expression". When Perl sees

        if (@foo) { ... }

        it evaluates @foo as an expression, and in that context it returns true. If I were to invent a "boolean" built in similar to the "scalar" built in, which forced "boolean context", then the above code would desugar into

        if (boolean(@foo)) { ... }

        Just as

        my $foo = @foo;

        desugars into

        my $foo = scalar @foo;

        Now in the context of Moose, when you assign a value to an accessor it does not impose the "b