The results are functionally equivalent to@copy = @tied;
as opposed to (what I'd more expect):my $length = $#tied; @copy[0..$length] = @tied[0..$length];
I've seen this on both 5.005 and 5.6.1 (but haven't tried 5.8).@copy = (); push @copy, $_ for @tied;
So the question really is: is this how it should be? Is it my own stupid fault for implementing a FETCH method that actually alters the size of the tied array? If so, it should probably be explicitly documented that this is bad form. Really, I suppose that the best possible thing might be to add a FETCHALL method to the tiearray interface. Certainly, most array ties would define FETCHALL to be
but it would be nice to be able to override it when necessary.sub FETCHALL { $self = shift; map { $self->FETCH[$_] } 0..$self->FETCHSIZE; }
Anyway, I'm just curious. Thanks.
--
For anyone curious, though, this really does not interfere with how r.pm works... at least not for perl -mr -n ... (or perl -mr -p) type stuff... since the <> operator really functions like it is shifting the contents of @ARGV, not copying the array. Also, I know that I haven't "officially" released r.pm, yet, as I'm still wading through legal processes with my employer, with respect to who owns what IP, and what they would let me do with it, etc.
In reply to Copying a tied array by etcshadow
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |