Re: Using ArrayRef data members in Moose

[dragonchild]

Take a look at http://search.cpan.org/src/SARTAK/MooseX-AttributeHelpers-0.12/t/002_basic_array.t - that's the test that exercises the AttributeHelper that provides an array. You kinda have to look at it sideways a bit, but everything's there. The rosetta stone might be at the bottom.

This does bring up an interesting question - how much of this do you really want Moose to do? This isn't idle speculation, either. I wrote some of the initial pieces of Moose with stvn and I think it's a phenomenal piece of work and should be used by most people in most places. Except, I've never used it in either work, OSS, or play. Part of that is I am completely comfortable with Perl's OO systems, having written about 4 myself and debugged several others. Part of that is that most of my work predates when Moose was actually usable. Part of that, though, is that I just don't drink that much koolaid. At some point, the syntactic sugar just gets to be too much and it's just simpler to go to another language like Ruby, Python, Javascript, or Smalltalk. Even stvn would agree that some of the really esoteric bits of Moose aren't ever going to be usable. Sometimes, a blessed hashref with cut'n'paste mutators is the right way to go.

sub foo {
    my $self = shift;
    $self->{foo} = shift if @_;
    return $self->{foo};
}

I'm not arguing against frameworks. I love them. I'm just saying that sometimes, a framework is inappropriate and you should learn to tell when that is.

[TGI]

dragonchild, what you wrote really resonates with me. Moose looks incredibly shiny. But when I need to get something done, I find myself throwing something together with Class::Struct or "classic" blessed hash-refs.

If I were to start a new complex, large project, I would seriously consider Moose (and build some test code before committing to it, you can be sure). But for most smallish projects, a hashref is plenty good enough.

[stvn]

At some point, the syntactic sugar just gets to be too much and it's just simpler to go to another language like Ruby, Python, Javascript, or Smalltalk

And give up CPAN? Silly hacker, no cookies for you! :P

We would all love to live in a perfect polyglot world (especially a programming language fetishist like myself), but it just simply does not exist in reality. The level of sophistication of Perl libraries and the amount of battle testing the best ones have endured is the whole reason that I wrote Moose (surely you remember, you were there :P).

Even stvn would agree that some of the really esoteric bits of Moose aren't ever going to be usable.

Nope, I would most definitely NOT agree with you on that, not in the least :)

The deep esoteric bits are not there for the casual user, they are their for the deep meta-hacker, or the MooseX:: author. Moose is layered as such that you only need to use as much as you want too, there are many rest-stops on the way down the rabbit hole.

Sometimes, a blessed hashref with cut'n'paste mutators is the right way to go.

Sure if you get paid by the LOC or better yet get paid by the hour so you can make the big bucks tracking down typo-bugs. Implementing (and re-implementing and re-implementing and re-implementing) the mechanisms of OOP for every single class is just plain wasteful, as wasteful as it would have been for me to have re-typed "and re-implementing" 3 times above instead of using copy/paste.

[spacebat]

Sometimes, a blessed hashref with cut'n'paste mutators is the right way to go.

That's when I use Coat;

Sure Moose tries to only pull in the parts you need, but it does rely on a fair few dependencies for what I want 95% of the time, just a simple class builder.

Here's hoping Moose makes it into 5.12 Core (but not likely!)

[stvn]

That's when I use Coat;

Actually the recommended mini-Moose is now Mouse, it was written by and maintained by one of the core Moose contributors and unlike Coat it is commited to stay 100% compat with Moose (it even has a module Squirrel which will choose Moose or Mouse depending on if Moose is already loaded or not). This is of course not to say that Coat is a bad choice, only that the author has decided compat with Moose is not as important to him, so if that is important to you, then use Mouse.

Here's hoping Moose makes it into 5.12 Core (but not likely!)

Here is hoping it doesn't!!

When a module goes into the core it suddenly has a dual-life. There is the (frozen) version that is distributed with the latest version of perl, and then the (living) version that is on CPAN (you now, the one with the bugs fixed and new features). Not until Moose is completely bug free and feature complete will I allow it to get put into core, in other words, it is never going to happen :)

[parv]

wrote stvn thus:

When a module goes into the core it suddenly has a dual-life. There is the (frozen) version that is distributed with the latest version of perl, and then the (living) version that is on CPAN (you now, the one with the bugs fixed and new features).

Indeed! Would be nice to see a lean core, for if a bug happened to be in only the "core" version, then explicit work is needed to pick up the updated version (from a different path).