On Thu, Aug 17, 2006 at 12:55:54PM -0700, Chip Salzenberg wrote:
> {DESIGNER ALERT - Allison, what think?}
>
> On Thu, Aug 17, 2006 at 12:31:11PM -0700, Patrick R. Michaud via RT wrote:
> > I rely on the "return empty string" behavior. In particular, changing it
> > to return NULL will mean in many places that I will have to replace
> > single-line key lookups
> >
> > $S0 = hsh['key']
> >
> > with
> >
> > $S0 = hsh['key']
> > unless null $S0 goto label
> > $S0 = ''
> > label:
>
> Indeed. I think we can reduce the pain of dealing with this to the point
> where you'll hardly feel it. For example, I really like Python's lookup
> semantic where you can provide the default value on the call.
FWIW, I reviewed the PGE code and found only five cases where I think
the code will have to change if hsh['nokey'] returns NULL, so I have to
substantially reduce the weight of my previous objection. (I still
think it's nicer if get_string_keyed always returns a string, the same
as get_int_keyed and get_number_keyed always return an int or num, but
it's not a major pain for me if it doesn't.)
> 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'], ''
I can think of a lot of cases where this would be really useful to me.
Pm
