Austin Hastings wrote:
--- 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)/
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.

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

Reply via email to