Chip Salzenberg wrote:
How about a 'default' opcode that provides a value instead of null? It
would work for strings and PMCs. Something like:
$S0 = default hsh['key'], ''
or
$P0 = new .Undef
...
$P1 = default hsh['key1'], $P0
$P1 = default hsh['key2'], $P0
...
It would work without the lookups too:
$S0 = default $S0, '' # if $S0 is null, assign it ''
what say?
This is a great feature. The name is confusing, it seems more like it
should be setting a default on the object than retrieving a value with a
default. If you follow Python's example, that would be just 'get' (or
'set' in Parrot) with an extra argument, but that's even more confusing
for different reasons. It almost makes the most sense as a variant of a
test for Null:
$S0 = isnull $S1 # returns a true/false value
$S0 = isnull $S1, '' # returns the value of $S1, or '' if $S1 is null
To look at the problem from another angle, how much is the choice of
default likely to vary from one access to another, and how much is it
likely to be something that's consistent for all accesses to a
particular hash? Individual HLLs will certainly have different defaults
for what their data structures return when looking up a key that doesn't
exist.
Out of curiosity, I did a little digging: Python 2.5 has added a
__missing__ hook to set the whole data structure's default for accessing
a key that doesn't exist.
<http://docs.python.org/dev/whatsnew/other-lang.html>
Here's some discussion that surrounded that design decision:
<http://mail.python.org/pipermail/python-dev/2006-February/061261.html>
What about allowing the Hash constructor to optionally set a default
return value for the hash?
Allison
