in reply to Re^2: Inexplicable uninitialized value when using (?{...}) regexp construct.
in thread Inexplicable uninitialized value when using (?{...}) regexp construct.

I got bitten by this a few times early on, without necessarially realising that the cause was the closures caused by using lexicals in the code blocks. I just found that using our and/or local meant things worked as I wanted them too.

This is one of the few places where the closure behaviour of Perl's lexicals is distinctly not useful.

I've never seen any mention of this in the POD, though it has come up here and on p5p a few times. I think a documentation patch is a very good idea, though I have my doubts as to the usefulness of a full explanation of the causes and effects. I think a simple "Don't use lexicals in code assertions!" would probably suffice, be more beneficial and less confusing.


Examine what is said, not who speaks.
"Efficiency is intelligent laziness." -David Dunham
"Think for yourself!" - Abigail
"Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon
  • Comment on Re^3: Inexplicable uninitialized value when using (?{...}) regexp construct.

Replies are listed 'Best First'.
Re^4: Inexplicable uninitialized value when using (?{...}) regexp construct.
by davido (Cardinal) on Sep 29, 2004 at 01:15 UTC

    Does this sound reasonable?

    perlre

    Inside the (?{...}) block, $_ refers to the string the regular express +ion is matching against. You can also use pos() to know what is the c +urrent position of matching withing this string. + Currently, lexical (my) variables within a (?{...}) block can be + problematic, as their use may lead to the unintentional creation of + a lexical closure. For that reason it is usually advisable to + use globals in (?{...}) blocks. The code is properly scoped in the following sense: If the assertion i +s backtracked (compare "Backtracking"), all changes introduced after +localization are undone, so that

    Dave

      Makes sense to me, but the guys on p5p will have better critique. I think I might make the last bit:

      + use (preferably localised) globals in (?{...}) blocks.

      Examine what is said, not who speaks.
      "Efficiency is intelligent laziness." -David Dunham
      "Think for yourself!" - Abigail
      "Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon