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.
Without JavaScript enabled, you might want to
use the classic discussion system instead. If you login, you can remember this preference.

Please Log In to Continue

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.

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 {... }ENDcroak($@) 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

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.