Front page | perl.perl5.porters |
Postings from June 2017
Paul "LeoNerd" Evans wrote: >Except its wording here isn't quite right. What %^H does is that values >are stringified at the point when compilation is over and runtime (for >that block) starts. No, perlvar(1) is closer to the truth. What *actually* happens is that anything written to %^H is immediately stored in two places. It's stored as-is in the actual %^H hash, but it's also stored in a flattened form (involving stringification of references) in an alist-like structure that hangs off the COP of compiling code. During compilation, the %^H content applicable to the current point of compilation can be read straight from %^H. By nature this yields the actual value that was written, including references as references. However, this mechanism can't examine the %^H content for any location other than the present compilation point. At any time (compilation, runtime, whatever), the %^H content applicable to any piece of compiled code can be read from the alist referenced by its COP. This yields the flattened value. The flattening is the cost of this being available for code other than that which is currently compiling. So what distinguishes between stringified references and intact references isn't timing, it's the mechanism from which the value is being read. The note in perlvar(1) about "at runtime" refers to the fact that reading %^H for currently-running code must be via the COP, hence in the flattened form. perlvar(1) is slightly wrong in saying "the entries are stringified when accessed", and you're wrong in saying they're stringified "when compilation is over": they were actually stringified during compilation, at the same time they were written into %^H. >If this is the case: does anyone have any suggestions on how I might >stop it triggering a warning from my code? Detect that the stringification is being performed for %^H-in-COP purposes and refrain from warning in that situation. > I feel that _charnames.pm >is doing something slightly naughty here, It is not at all naughty. The compile-time behaviour of %^H is intentional and supported, and predates by two major versions the availability of the shadow of %^H in the COP. -zeframThread Previous | Thread Next