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
Why not Moose
More |
Login
| Reply
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
--Mark Hahn, <hahn@neurocog.lrdc.pitt.edu>
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
Moose isn't as bad as Switch.pm (Score:1)
Moose has it's issues... certainly the big memory overhead and the slow startup are issues.
(Yes, I know they are working on it, and it's gradually getting better...)
But even though it's heavy, source filters are up there in a whole different (worse) class of crazy, as it the original bad implementations of Inside Out objects.
But you have to remember that this weight is there for a reason, and that's to allow not-brilliant programmers to do useful work without hurting themselves as seriously.
Reply to This
Re: (Score:0)
You mean it's coded defensively, robustly? Well, I wish a few more "brilliant" programmers would try that. I thought it was because of all the metaclass/introspection stuff. (I'm recently liking Moose. Add a couple modules like MooseX::Params::Validate and MooseX::StrictConstructor, coercing parameters to types, before/after/around, ah it's not bad... Slower, maybe (co
Re: (Score:1)
Switch.pm has no dependencies. It's short. Moose has many deps and lots of code. Certainly source filters carry a lot of bad juju. Moose is huge and complex. I can't honestly say that that makes it "as bad" as Switch, but I think the analogy is fair. Or, as I said in another comment, comparing it to Inline::C vs XS might have been more fair. When distributing modules on CPAN, it's much better to use XS. Using Inline::C, which though it's awesome and generally works well, you're piling magic on top o