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 guess that your example above is a gross simplification of what you're actually trying to do?

    In fact, re-reading your post, you say:

    While I now know that I can just use Moose::Meta::Class to do this, but this is actually a problem I encounter from time to time in other contexts and rather than explicitly doing a string eval (which breaks syntax highlighting and hides the code from PPI), I'd like that 'repackage' to handle that.

    As I'm sure you know, your example above can be written as:


    • When I say "other contexts", I just mean that I do a lot of code generation work and I often need to dynamically declare a package. Deferring code compilation via eval is a common enough thing in general that I think it's worth generalizing it.

  • 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 { ... }
      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 :)

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


  • Um. I think Piers's post is from March: the docs for DD were released in April... Yes indeed, the current docs are the friendly, useful version ;)

    The ::Simple modules are indeed still undocumented as you point out, but patches welcome!