Slash Boxes
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

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • I wrote Class::Accessor::Classy because I was sick of the Class::Accessor approach of "you must inherit the meta class." This was when Moose was still very young, but I still don't see the speed in Moose. C::A::Classy certainly lacks a lot of the features of Moose, but it is fast and light enough to be a foundation for serious work without getting in the way.

    I do occasionally want something which Moose would provide beautifully, but paying speed/size for the whole thing while only using 2% of the features 98% of the time simply doesn't work for me.

    I wish Moose would run much faster and lighter, but it's difficult for me to see where investing my own effort (in both learning and contributing) would yield results with sufficient performance. Unfortunately, this was also true over a year ago. Until `perl -e 'require Moose'` clocks under 1/100th second, I'll simply have to keep working with something simpler.

    I really do wish that I had nothing against Moose. That is, I wish there were "one really good way to do it" and that everyone did that. But, it has to perform or it doesn't fly.

    • Try "Badger" from Andy Wardley.

    • If you have commandline applications or CGI applications that are extremely response-time sensitive You should really see if Mouse can work for you. It's got more update and active development than any of the other OO frameworks from what I can tell, with speed as it's reason for being. That being said, I write commandline apps with Moose and find it more than responsive enough. Your sensitivity my be different than mine though.
      Waiting on the Road to Eventually, I lost my Place On Line
      • Yup, I'm aware of Mouse. And I'd encourage people writing modules that have deps (which is what triggered the original post) to use it instead. I might even use it, but I enjoy doing other things too much >=)

        Speed is only one way in which the abstractions created by Moose leaks. I was just asking that people who write modules consider the law of leaky abstractions in general before using Moose in modules not related to Moose. And then doing some off topic bitching ;)


    • If I were writing an enterprise app, I'd seriously consider Moose, but what has me scratching my head is 30 line "helper" modules pulling it in. It reminds me of the Simpsons episode where the IRS took over Krusty Burger and Homer has to fill out a bunch of paperwork to get a burger. It's just comically top-heavy. Sure, the module helps, but at what cost?

      I wouldn't feel too bad if every program that used a module wound up with Mouse loaded, but if it happens that you can't use anything without Moose gett

      • I just installed Method::Signatures. It required PPI, Devel::Declare::MethodInstaller::Simple (B::Hooks::OP::Check), Devel::BeginLift. Doesn't all this (presumed) perlguts manipulation seem....fragile?