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

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.
  • Right, but I don't get how dynamically generate/declaring a package using Moose isn't waaay easier and nicer than using a string eval?

    What problem are you trying to solve that won't work by just generating classes through the meta-model, or why does that solution not work for you?

    As an example of this taken to extremes, see the tests for my CX::DynamicComponent dist - I generate the models for my application totally dynamically from configuration, and then go on to generate the application controllers dynam

    • I only used the Moose example because that's what I was working on today. I still have found myself on several occasions writing this:

      eval <<"END";
      package $package;
      our \@ISA = $some_base_class;

      sub some_sub { ... }
      END
      croak($@) if $@;

      So yet, I definitely found the Moose meta stuff was easier and nicer than a string eval, but again, I often need non-Moose packages generated at runtime and the code bound to that package. This often requires string eval (and it quickly gets very annoying if you want t

      • I often need non-Moose packages generated at runtime

        Right, I guessed that this was where you were going, but why do they need to be non-moose classes? Sure, if you don't need all of Moose, use the Class::MOP api.

        Your generated classes don't have to subclass Class::MOP::Class, don't have to have a 'meta' method, it all still works..

        All I'm hearing is you saying 'string eval sucks', which is totally correct.. I still don't understand why you think you need to use it to solve your issue.

        If you really need th

        • Right, I guessed that this was where you were going, but why do they need to be non-moose classes?

          A package might very well be procedural code and not class-based. Plus, for wanting to abstract away this code, why would anyone thing "I must now use Moose or Class::Mop"? That's a straight jacket which is just wrong :)

          • by bobtfish (8386) on 2009.06.20 6:13 (#69119)

            Nothing but nothing is stopping your from using the MOP to construct packages without constructors which you call procedurally. Hell, you can just use Class::MOP::Package standalone to at least get away from manual symbol table twiddling.

            And yes - TIMTOWTDI. If you really want the originally floated syntax without requiring MOP then you're gonna need another technique, and Devel::Declare is a good way of not doing string concatenation fed into eval, but it also involves a lot more fiddling with perl guts.

            Also - is Devel::Declare really a less exacting (or at least platform constraining) dependency requirement than plain MOP?

            Either way - can we call my solution laziness, plain string eval with concatenation impatience, and your solution hubris, and have done with this discussion?

            They all have advantages and disadvantages, and if you write it - I'll probably use it at some point - I was just trying to point out that this isn't the only way to achieve what you want..