Wow, you really do seem to be bothered by Moose, which is odd cause you not only don't seem to have ever used it.

There are no methods, beyond getters and setters, which hashes and arrays already know how to do. In the process, you've hidden all the other things they know how to do. Like:

• For the hashes: each, exists, defined, keys (in scalar, array and lvalue contexts). values (in scalar, array and lvalue) contexts, delete, undef.
• For the arrays: pop, push, shift, splice, unshift, $#array, delete, undef; plus their various contextual variations.

Some of these can be exposed through the addition of generated methods, but all of them? And at what cost? Different names to the ones every half-experienced Perl programmer is already familiar with. get_size() and put_size() instead of $#array as an lvalue.

All I have to say to that is Moose::Autobox. It will give you your standard names and avoid the "generated methods" overhead.

And note also, that this is just the number of lines you wrote. It doesn't include the whole of Moose::* and its dependencies: Class::MOP, ( and its dependencies: Sub::Name, MRO::Compat (and its: Class::C3 (and its: Algorithm::C3 ) ), Sub::Exporter (and its: Params::Util, Sub::Install, Data::Optlist ) ).

Sure, it is a lot of code, but installing it is not really a big issue. We have a pretty decent (usually above 80%) chance of install success on 5.8, 5.8.8 and 5.10.

And I've left out all those that can generally be expected to be a part of the standard distribution (despite that it requires the latest cpan versions of most of them).

Well, thats mostly because some of the non-latest version are broken (standard install of Scalar::Util on several platforms is missing the XS version and therefore it's weaken support, this is such a problem that Task::Weaken was created to try and fix it). This is the curse of Core modules, they get frozen in time even if they are broke.

Including Filter::Simple, which means source filters! (Though I had no luck in working out where in the pile of modules this is actually used?)

Hmm, you didnt look to hard then, it is pretty obvious in the Makefile.PL.

# only used by oose.pm, not Moose.pm :P
requires 'Filter::Simple' => '0';
[download]

Perhaps you need better glasses, or maybe to just clean all the FUD off the ones your wearing.

Now the typical reaction to this is "So what"...its all code I didn't have to write and don't have to maintain myself". But when something goes wrong you'll wish you could maintain it yourself.

Why would you ever, ever, EVER take on maintainence of a module when you could simple submit a bug report? Abandoned modules are one thing, but none of the ones you listed are in any danger of being abandoned any time soon. That statement is just plain silly, by your logic using *any* modules is a bad idea, core or not.

And really, if something goes wrong, be a responsible community member and submit a bug report, speaking for Moose specifically I can say that we usually turn around bugs pretty quickly. Currently we have 2 "wishlist" items from Schwern and a bug with threading which we are looking for someone who actually uses threads to help with, cause most of the #moose crew do not (seems like it is related to a usage of some more advanced regexp features too, and not related to core Moose). Bugs submitted over IRC or the mailing list tend to be taken care of within a few days though.

Because when it turns out that the ref-count manipulations in lines 458 & 459 of Class::CS::XS are causing a memory leak, which manifests itself as coming from an anonymous sub generated by the string eval in Class::MOP::Method::Accessor ...

Funny, I am not seeing your bug report for Class::C3::XS or for Class::MOP. The C3::XS code is also in 5.10, and I am not seeing a bug report there either.

Are you just making stuff up? Or is this a real issue? Seriously, the FUD coming off you is overwhelming at this point.

... and you're urgently trying to get your application back on-line, and the authors of the dozen or so packages involved are arguing about who needs to change what.

One would think that proper testing would have weeded out this issue before it got to production. But assuming that didn't happen, it should be pretty simple, Brandon Black maintains Class::C3::XS and I maintain Class::MOP and we have worked together on several things before. Sure, that kind of immature cat-fighting might happen sometimes in the CPAN community, but it is certainly not the norm. *cough* excuse me,.. sorry the FUD is making it hard to breath *cough*

At that point, you'll wonder about the efficacy of replacing Perl's reliable built-ins for such complexity, all for the sake a little syntactic sugar.

So don't use it, that simple. Oh, and btw, where do they keep Perl's reliable built-in Meta Object Protocol? Cause I must have missed that bit when I wrote Class::MOP. Moose may look like just syntactic sugar, but I assure you the rabbit hole goes much deeper then that.

Especially as it means you have to write more code to start with, the complexity of the code you write is increased, and the resultant code is if anything less readable than standard Perl.

In general, for larger applications then this one, Moose means less code.

Also with Moose, the code complexity is most times actually reduced since many things you would have to do manually over and over, like accessors, are done for you. This greatly reduces the likeliness of copy/paste induced bugs which tend to creep into tedious code like accessors.

As for the readability, once you know Moose, the code becomes very readable. If you don't know Moose, then that wont be the case. But then again, this is true of all languages, computer or otherwise. Unless, wait,.. do you have some secret programming language you created that can be instantly understood and comprehended by anyone anywhere without them having to learn it? If so please release it so the world can benefit from it ;)

Love and Kisses,