Shouldn't access to 'is computed' arrays be read-only?
If you want to be able to consume the elements by shifting,
you can always create a tied object that kees a cursor and
a reference to the underlying array and gives you that
access (and it could die for splicing, etc.)...
Regards,
-- Gregor
Michael Lazzaro <[EMAIL PROTECTED]>
01/30/2003 02:25 PM
To: [EMAIL PROTECTED]
cc:
Subject: Arrays: is computed
For C<is computed> arrays, things get more complicated. Since there
are no true 'holes' in a primitive-typed array, the correct behavior
there would seem to be to autofill the array using the computed values.
For example, an empty array:
my int @a is computed { $^index ** 2 }
@a[2]; # 4 (doesn't exist, is computed)
@a[3]; # 9 (doesn't exist, is computed)
@a[4]; # 16 (doesn't exist, is computed)
Now setting an element:
@a[4] = 0; # (setting an element autofills previous elements)
# @a now contains (0,1,4,9,0)
@a[2]; # 4
@a[3]; # 9
@a[4]; # 0
@a[5]; # 25 (still doesn't exist, is computed)
@a[1000] = 0 # (calls the computed sub 1000 times, hope ya meant
it)
Again, note the dubious behavior of doing a C<shift> or other
manipulation on any C<is computed> array. The autofilled portion would
shift, but the computed portion would not:
my int @a is computed { $^index ** 2 }
# at first, @a is entirely computed,
(0,1,4,9,16,25,...)
@a[4] = 0; # @a now contains (0,1,4,9,0);
# now (real) + (computed)
shift @a; # (1,4,9,0) + (16,25,...)
shift @a; # (4,9,0) + (9,16,25,...)
shift @a; # (9,0) + (4,9,16,25,...)
shift @a; # (0) + (1,4,9,16,25,...)
shift @a; # () + (0,1,4,9,16,25,...)
Not saying that's wrong. Just very, very wacky. And yes, it's fixable
if every array has an "offset" number that's always updated to mark how
far the array has been shifted/unshifted from it's starting point. But
I'm not suggesting that. Really.
MikeL
