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.

Package::Dynamic As Yet Unwritten 5 Comments More | Login | Reply /

 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 to work around it).

      • 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 :)

          • 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.

            Al

Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.