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