New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
localised tied scalar referenced elsewhere has strange effects #11763
Comments
From @cpansproutThis is based on rt.cpan.org #53064. sub TIESCALAR{bless[], $_[0]} That script prints: storing one at - line 3. If you comment out the my $x = "$a" line and uncomment the line below it, you get: storing one at - line 3. So apparently the "$a" is skipping get-magic. In any case, ‘$b is now one’ seems like the correct output to me. The hard part is figuring out how it is supposed to work. When you write ‘local $foo’ on a regular scalar, the *foo{SCALAR} slot is temporarily replaced with another scalar. If you have a reference to the original $foo elsewhere, you can modify it even during the localisation. The modified value of $foo is what is visible after the localisation goes out of scope. Localised tied scalars are a different creature. The scalar is replaced with a new scalar, like an untied variable, but then the new scalar is tied to the very same object. The old scalar has its private flags copied to the public flags, so that a simple SvSETMAGIC will restore the previous value. But that implementation detail leaks out as through a sieve when a reference to the original scalar exists elsewhere. That is why "$a" is skipping FETCH. Since the new tied variable is tied to the same object, conceptually it could be considered the same scalar, just with a localised *value*. Most people probably think of it that way. If we make the implementation actually work that way (copy the value to a new scalar and put that on the save stack; assign the value of that temporary scalar back to the tied variable on scope exit), it will at least be self-consistent. Is that a good idea? Flags: Site configuration information for perl 5.15.4: Configured by sprout at Wed Nov 2 09:06:14 PDT 2011. Summary of my perl5 (revision 5 version 15 subversion 4) configuration: Locally applied patches: @INC for perl 5.15.4: Environment for perl 5.15.4: |
From @rjbs* Father Chrysostomos <perlbug-followup@perl.org> [2011-11-20T19:37:23]
Not only are they different from untied scalars, but also from tied arrays and Tied arrays and hashes cease to be tied after localization, after some work by http://www.xray.mpe.mpg.de/cgi-bin/w3glimpse2html/perl5-porters/2010-04/msg00561.html In fact, tied scalars were also no longer tied after local, after that thread, http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2010-05/msg00627.html David Golden notes that this change broke File::chdir and Dave Mitchell says It's a tough nut. The current behavior stinks, and breaking stuff stinks, and -- |
The RT System itself - Status changed from 'new' to 'open' |
From @xdgOn Mon, Sep 17, 2012 at 6:56 PM, Ricardo Signes
I can only repeat my comments at the time: tl;dr: I'm happy for it to be consistent even if that breaks stuff. More generally, I find tie() to be a huge PITA and it's on my David -- |
From @jkeenanOn Mon Sep 17 17:42:54 2012, xdg@xdg.me wrote:
"fix-it-with-a-Delorean" stumps me ... as well as DDG, Google and Bing! Example: https://duckduckgo.com/?q=fix-it-with-a-Delorean |
From @b2gillsOn Mon, Sep 9, 2013 at 6:23 PM, James E Keenan via RT
"Fix it with a Delorean" is obviously a "Back to the future reference. You could also say "fix it with a/the TARDIS" Basically it means going into the past to prevent the mistake from |
Migrated from rt.perl.org#104118 (status was 'open')
Searchable as RT104118$
The text was updated successfully, but these errors were encountered: