Austin Hastings wrote:
Unfortunately, I don't think we can base defaultitude on the (non)existence of an array element. You end up with some rather nasty action-at-a-distance.--- Austin Hastings <[EMAIL PROTECTED]> wrote:No, undef. OTOH, deleting @a[1] would reset it to default.Ere someone flames my for using a hash keyword in an array context: s/deleting/absquatulating (e.g., via pop, shift, or splice)/
Consider:
my @a is default(666);
print @a[2]; # prints 666
@[4] = 1;
print @a[2]; # now prints undef :-(
I think of C<is default> as specifying a mapping from an implicit or explicit
C<undef> to something else.
I'm not compelled by the counter-argument that this makes it impossible to store an C<undef> in an array with a default. Because the whole point of an array having a default is to prevent those nasty out-of-range C<undef>s from popping up in the first place.
And thinking of defaults as mappings leads me to conclude that it's
entirely reasonable to allow sub refs as default specifiers, as a means of creating computed arrays. But I'd expect that the property name is different in that case (probably C<is computed>), so as to distinguish:
# array of subroutine refs
# (default value returned is reference to identity function)
my @funcs is default { return $^arg } = (
{ return 1 },
{ return $^arg ** 2 },
{ return $^arg ** 3 },
# etc.
);
from:
# array of data values
# (default value returned is square of requested index minus 1)
my @vals is computed { return $^index**2-1 } = (
2,
3,
7,
# etc.
);
Damian