On Wednesday 29 January 2003 09:52 pm, Rick Delaney wrote: > 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. > 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. >
This makes more sense to me. Say an array has a default. If we use an uninitialized slot in the array, we should get the default. Fine -- we have to initialize the thing anyway. But I think it's much saner to have this: * Have an 'undef' or 'unset' unary operator that sets the slot to the array's default (if there is one), and if there isn't then do whatever (either set to the 'default default' or undef, or actually delete the item if it's practical -- it's a minor detail, and not really my point.) * If we try to assign undef, or 0, or whatever, to a slot, then we put the closest thing to undef or 0 that we can, and not the default. Yes, there's some merit on checking whether we're actually assigning "real undef", and not just whatever undef converts into, but that also causes some problems with copying arrays and reading data in and out. Basically, I think it amounts to handling defaults on the setting end, rather than the getting end, which seems a lot more practical to me. I think that having @a[1]=0; print @a[1]; not print '0' is scary voodoo no matter what the reason, and I like having to undefine things with something other than assignment. Possible caveat(s): * Copying arrays. If we handle the "set to default" case sloppily, and then try to copy into an array which has a different default, then some items that were supposed to be 'undefined' are now defined and have the default from the source array. Not good. * Might be inconvenient if we want to dump out to some plain-text format and read back in, as we would have to write code that's explicitly aware of the existence of a default. I'm getting long-winded here, but what it seems like is: what some people seem to be thinking has a lot of potential for hidden action and foot-shooting. What I'm saying seems to me to be 'safer' but maybe less convenient in some situations. Hrm... I think both behaviors could be done without too much pain from user code wrapping an array (even an array of primitive types), so maybe it's a moot point anyway -- just give the user the choice whether they want to risk cutting off limbs with the swiss army chainsaw. Anyway, cheers and good discussion --Andrew "hobbs" Rodland < arodland at noln.com >
