in reply to Re^3: trouble with packages/eval/variable-scoping
in thread trouble with packages/eval/variable-scoping

That's kinda cool if it works (can't test ATM)

But this relies on constant folding happening after the PAD was populated.

I'd feel uncomfortable to use an undocumented feature and risk to run into problems in later perl versions.

IIRC they started to deprecate the similar my $var if 0; (poor man's state ) so I'm kind of sceptical that's guaranteed to stay.

Cheers Rolf
(addicted to the Perl Programming Language :)
see Wikisyntax for the Monastery

Replies are listed 'Best First'.
Re^5: trouble with packages/eval/variable-scoping
by ikegami (Patriarch) on Aug 29, 2024 at 17:00 UTC

    But this relies on constant folding happening after the PAD was populated.

    That's pretty much necessary. But let's imagine it's not.

    Anything that can be optimized away would run into that problem. It's hard to write a version that doesn't warn and can't be optimized away. For example, look at the following:

    my $false = 0; # Perhaps a global. capture( $gold ) if $false; # `capture` doesn't need to exist.

    Even that could be optimized away. And that's far from readable.

    Since the symbol table is externally modifiable, the following can't be optimized away and provides a solution:

    sub capture { } capture( $gold );

    It does comes at a performance cost. You could, of course, use an opcode checker to optimize the call away. But then we're back to the beginning.

    Actually, not really. An opcode checker manipulates ops, so that means the padop for $gold must have been created already. So that might be a very simple module that makes the intent clear.