On Wed, Jan 29, 2003 at 01:54:10PM -0800, Michael Lazzaro wrote:
>
> On Wednesday, January 29, 2003, at 12:38 PM, Smylers wrote:
> > That would make the rule very simple indeed:
> >
> > Assigning C<undef> to an array element causes that element to take
> > the
> > array's default value.
> >
> > The effects of this are:
> >
> > * Assigning a particular integer to an array of int or Int always
> > does
> > what it looks like it's doing, irrespective of whether or not that
> > integer is zero or whether the array happens to have a default.
> >
> > * In an array of Int, attempting to store C<undef> will, by default,
> > actually store C<undef>. If the array has a different default
> > defined then that will be stored instead.
Wouldn't that mean that this would loop forever?
my @a is default("foo");
#...
# please excuse my garbled perl5/6 syntax
print "@a" while $a[0] = <FILE>;
I'd also like to point out that ruby has defaults for hashes but
assigning nil (the equivalent of undef) does not set the default; delete
does.
> > * In an array of int, attempting to store C<undef> will, by default,
> > store zero. If the array has a different default defined then that
> > will be stored instead.
>
> That has merit. One question -- with this approach, attempting to
> store an C<undef> in an array of int therefore silently succeeds
> (there's no longer any "converting undef to 0" warning, right, since it
> would be triggered constantly by this mechanism?)
It seems to me that the conversion of undef is separate from the notion
of a default.
my int @a;
is like
my int @a is undef_to(0).
There is no default here, only a rule saying what assignment of undef
stores. Accessing an uninitialized element should raise an exception,
not give zero.
In the case where people want assigning undef to set the default (i.e.
treat undef the same as uninitialized) then they would set both
properties to the same value.
my int @a is default(1) is undef_to(1);
--
Rick Delaney
[EMAIL PROTECTED]
