in reply to Re: (??{ code }) versus (?PARNO) for recursive regular expressions
in thread (??{ code }) versus (?PARNO) for recursive regular expressions

My previous time using (??{ code }) 5 years ago, I declared everything using our and of course did use strict. However, that doesn't have any effect on this code now:

our $braces_re = qr/ ... (??{ $braces_re }) ... ) /sx;

[download]

Still throws a strictures warning. The only way I've observed being able to get it to work now is by having the variable predeclared, regardless of whether it's done using my or our.

If it helps, it probably was more like 9-10 years ago. Basically very soon after the (??{ code }) feature was introduced.

Replies are listed 'Best First'.
Re^3: (??{ code }) versus (?PARNO) for recursive regular expressions
by ikegami (Patriarch) on Mar 25, 2011 at 22:47 UTC

    Still throws a strictures warning.

    Of course. Variable declarations includes our.

    These work: 

    1. no strict;  $x = qr/(??{ $x })/;
2. use strict; our $x = qr/(??{ our $x })/
3. use strict; our $x = qr/(??{ no strict; $x })/
4. use strict; our $x; $x = qr/(??{ $x })/
5. use strict; my $x; $x = qr/(??{ $x })/

    [download]

    I think there was once a bug where some or all pragmas didn't propagate into (??{ }) and the like. If so, the following would have worked because it would have been equivalent to #3 above: 

    6. use strict; our $x = qr/(??{ $x })/

    [download]

    The earliest I have here is 5.10.1, and it doesn't have this bug.

[reply]
[d/l]
[select]

      Now I'm definitely going down the old memory train. When I first used the (??{ code }) feature, we had to declare our globals using vars.

      use vars qw($x_re);

$x = qr/... (??{ $x }) .../

      [download]

      This of course worked, but we were quite excited when they released our with perl561delta. Near that point in time, the following did work as desired without throwing errors:

      use strict;

our $x = qr/... (??{ $x }) .../

      [download]

      The thing as, as I understand the documentation of perlre, it should be allowed

      This is a "postponed" regular subexpression. The code is evaluated at run time, at the moment this subexpression may match.

      The whole point of being able to do a recursive regular expression is that you can include the qr// regex that you're currently defining. However, given the choices you listed above, I'd probably go with the following even if it does feel messy

      our $x = qr/... (??{ our $x }) .../

      [download]

      Anyway, putting all that aside, I'd still like to get back to my primary question. Is this a feature that I should keep in my toolkit, or should I just drop it in favor of (?PARNO)? I can't think of any situation currently where I'd need the former over the latter, but I would like to know if y'all would consider still using it or not.

[reply]
[d/l]
[select]

        The thing as, as I understand the documentation of perlre, [use strict; our $x = qr/... (??{ $x }) .../ ] should be allowed

        You're using a variable ($x) you haven't declared yet. It's a strict error just like 

        $ perl -e'use strict; our $x = $x;'

$

        [download]

        huh... what? I guess I was wrong. our declarations take effect immediately. I don't see why «our $x = $x;» and «our $x = qr/(??{ $x })/;» can behave differently. It would seem there's a bug here.

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom