Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister
 
PerlMonks  

Re^8: Getting for() to accept a tied array in one statement

by hdb (Monsignor)
on Apr 18, 2019 at 12:04 UTC ( #1232757=note: print w/replies, xml ) Need Help??


in reply to Re^7: Getting for() to accept a tied array in one statement
in thread Getting for() to accept a tied array in one statement

I have to admit that I am not a specialist on the Perl internals (more precisely I do not know anything about it), so my guess is the following:

If any element of LIST is an lvalue, you can modify it by modifying VAR inside the loop. Conversely, if any element of LIST is NOT an lvalue, any attempt to modify that element will fail. In other words, the foreach loop index variable is an implicit alias for each item in the list that you're looping over.

from perlsyn means that for anything that can be modified (i.e. an lvalue) in the loop's body, Perl must remember where it is stored. When accessing or modifying it, the tie mechanism is invoked. So this version

tie @ary, "My::Class", "some", "el", "ems"; for (@ary) { some_code($_); }

must have worked ever since tie exists. Using sub wrapper : lvalue {...; return @x} is only turning the result from the sub to be an lvalue (according to the docs since Perl 5.6).

Whether or not this is what is really happening I do not know.

Update: reversed lvalues seem to be fine as well:

my @arr1 = (0) x 4; my $n = 0; for( reverse @arr1 ) { $_ += $n++; } print "@arr1\n"; __END__ Output 3 2 1 0

Replies are listed 'Best First'.
Re^9: Getting for() to accept a tied array in one statement
by LanX (Cardinal) on Apr 18, 2019 at 12:58 UTC
    Wait now I am confused...

    I thought the whole spectacle is about hooking into the iterator on the arrays level.

    But you are talking about the lvalue character on the elements level...

    Probably I need to start reading the whole thread again ...

    Cheers Rolf
    (addicted to the Perl Programming Language :)
    Wikisyntax for the Monastery FootballPerl is like chess, only without the dice

      The magic of tie seems to be strong. Even when using a reference to an element of a tied array one cannot bypass the associated class. And the access through the reference provides the correct index. So is this what happens when Perl aliases elements in a loop?

      use strict; use warnings; package MyClass; use Tie::Array; our @ISA = ('Tie::Array'); our @data; # mandatory methods sub TIEARRAY { my $class = shift; bless \@data, $class; @data = @_ +; return \@data } sub FETCH { my ($self, $index ) = @_; print "FETCH($index)\n"; ret +urn $data[$index] } sub STORE { my ($self, $index, $value) = @_; print "STORE($index)\ +n"; $data[$index] = $value } sub FETCHSIZE { print "<FETCHSIZE> "; return scalar @data } package main; my @x; tie @x, "MyClass", 0, 0, 0; my $x = \$x[2]; $$x++; print "@x\n";

        I'm not good with tie, but thought I'd take this as a learning exercise. I was surprised by using our @data instead of a fresh anonymous aref for each instance, so I tied @y to the same class to confirm it (confirmed). I wanted to untie those variables and re-use them to tie to a second class that used separate data structures in TIEARRAY (in spoiler; the mods worked as I expected, with separate data structures for @x and @y)... but was surprised at the "untie attempted while 2 inner references still exist" warning when I did the untie. I thought the $x reference was probably the culprit, so undefined that.... but there was still one remaining inner reference. What is the second inner reference, and where did it come from?

        use strict; use warnings; package MyClass; { use Tie::Array; our @ISA = ('Tie::Array'); our @data; #mandatory methods sub TIEARRAY { my $class = shift; bless \@data, $class; @data = @_ +; return \@data } sub FETCH { my ($self, $index ) = @_; print "FETCH($index)\n"; ret +urn $data[$index] } sub STORE { my ($self, $index, $value) = @_; print "STORE($index)\ +n"; $data[$index] = $value } sub FETCHSIZE { print "<FETCHSIZE> "; return scalar @data } }; package main; $|++; local $" = ", "; my @x; tie @x, "MyClass", 0, 0, 0; my $x = \$x[2]; $$x++; print "x = (@x)\n"; =begin comment When I first saw the above, it looked like no matter how many items we +re tied, they would all refer to the same @MyClass::data internal arr +ay. The next few lines showed that's true: when I tied @y to the same clas +s, @x lost its data; and when an element of @y was changed, the same +happened to @x. =cut my @y; tie @y, "MyClass", 0, 0, 0; print "y = (@y)\n"; print "x = (@x)\n"; $y[1] = 3.14; print "y = (@y)\n"; print "x = (@x)\n"; untie @y; # gives a warning: untie attempted while 2 inner refer +ences still exist undef $x; # uncomment to reduce next warning to 1 instead of 2; +comment to keep next warning at 2 untie @x; # warning, but with only 1 warning if previous line un +commented print "y = (@y)\n"; print "x = (@x)\n"; # so what's the second inner reference?
        > So is this what happens when Perl aliases elements in a loop?

        if you are interested to find out using B::Concise might help.

        Cheers Rolf
        (addicted to the Perl Programming Language :)
        Wikisyntax for the Monastery FootballPerl is like chess, only without the dice

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1232757]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others contemplating the Monastery: (8)
As of 2021-04-12 20:11 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found

    Notices?