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

use Perl Log In

Log In

[ Create a new account ]

Ovid (2709)

Ovid
  (email not shown publicly)
http://publius-ovidius.livejournal.com/
AOL IM: ovidperl (Add Buddy, Send Message)

Stuff with the Perl Foundation. A couple of patches in the Perl core. A few CPAN modules. That about sums it up.

Journal of Ovid (2709)

Friday June 19, 2009
10:57 AM

Package::Dynamic As Yet Unwritten

[ #39150 ]

Piers Cawley has described Devel::Declare as possibly the most hostilely documented library [he's] ever come across. I'm hard-pressed to think of a more accurate description. For example, here's this gem from the docs:

For a simpler way to install new methods, see also Devel::Declare::MethodInstaller::Simple

The problem with that line is that Devel::Declare::MethodInstaller::Simple has no documentation at all! I now think I understand what's it's doing, but my brain hurts.

What I want to do is transform something like this:

repackage $some_package {
    use Moose;
    extends 'Some::Class';
    with    'Some::Role';
}

Into this:

eval <<"END_DYNAMIC_REPACKAGING";
package $some_package;
use Moose;
extends 'Some::Class';
with    'Some::Role';
END_DYNAMIC_REPACKAGING
if ( my $error = $@ ) {
    require Carp;
    Carp::Confess($error);
}

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.

In fact, delaying evaluation of a block until runtime is moderately common and that's really what we're trying to do here. Unfortunately, you have to call a string eval to do this. I think Devel::Declare can handle this, but the parser currently has me defeated. I'll try again later, but if you want to simply post the answer, I won't mind :)

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

    Moose::Meta:

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

          • 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

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

    --

    osfameron