Re: runtime "use" statements via string eval

In this case, you're trading compile-time compilation (there's a good catchphrase for people looking to quote me) for run-time compilation on every pass through the subroutine.

If it weren't for the string eval, I'd definitively say that you're not gaining anything on memory use -- if the subroutine is ever called -- as the eval() takes on the package context of the surrounding code. Any exported variables or methods will be installed in the current package table, as far as I understand it.

Granted, if the module has already been used, Perl will look in %INC to see if it's there. You'll still have to pay the (however slight) eval string penalty.

Besides all that, it's *generally* unclear and bad style, in my opinion. Unless there's a very compelling reason to do this, I'd whack somebody who suggested it. In general, there aren't many good reasons to use eval string.

Comment on Re: runtime "use" statements via string eval

Replies are listed 'Best First'.
Re (tilly) 2: runtime "use" statements via string eval by tilly (Archbishop) on Apr 04, 2001 at 17:42 UTC
Seconded with the proviso that "aren't many" is not the same as "aren't any". A quick counter-example is a subroutine that takes a number of options and returns a closure with a large number of optional hooks. In this case it can be very nice to have the closure be the result of an eval, with the text of the subroutine being assembled from just the hooks you use. In other words move the cost of the hooks to tests when you compile the closure, and not pay every time you call the closure. (As I pointed out to the author, if Pod::Parser had a slightly different interface it would be an excellent candidate for getting a massive performance boost from this trick.)	[reply]

Replies are listed 'Best First'.

Re (tilly) 2: runtime "use" statements via string eval
by tilly (Archbishop) on Apr 04, 2001 at 17:42 UTC

A quick counter-example is a subroutine that takes a number of options and returns a closure with a large number of optional hooks. In this case it can be very nice to have the closure be the result of an eval, with the text of the subroutine being assembled from just the hooks you use. In other words move the cost of the hooks to tests when you compile the closure, and not pay every time you call the closure. (As I pointed out to the author, if Pod::Parser had a slightly different interface it would be an excellent candidate for getting a massive performance boost from this trick.)

[reply]