Front page | perl.perl5.porters |
Postings from November 2010
On Mon, Nov 29, 2010 at 4:37 PM, Zefram <zefram@fysh.org> wrote:
> Jesse Vincent wrote:
>>safe-dereferencing arrow
>
> I think this name for it is problematic. There are many types of safety.
I agree. "Short-circuiting dereference" perhaps? Or "defined
dereference" or "conditional dereference"?
> Which dereference, and what constitutes success?
I think we should leave it as close to the original suggested use
case, which was to eliminate code like this:
$obj &&
$obj->{foo} &&
$obj->{foo}{bar} &&
$obj->{foo}{bar}->(42) &&
$obj->{foo}{bar}->(42)->{baz}
It was described more or less as "if defined, continue, otherwise
return undef". I noted in the original thread that the test is better
thought of as a nested ternary test:
defined($obj)
? ( defined($obj->{foo})
? ( defined($obj->{foo}{bar})
? ( defined($obj->{foo}{bar}->(42))
? $obj->{foo}{bar}->(42)->{baz}
: undef )
: undef )
: undef )
: undef
Instead, the proposal is to have simpler syntax like this:
$obj->>{foo}->>{bar}->>(42)->>{baz}
(replacing "->>" with whatever operator is finally chosen)
By focusing just on whether the LHS is defined, we solve the most
common situation, which is someone attempting to dereference an
undefined value. It leaves as an error condition trying to
dereference something incorrectly, which is more likely to be an
actual bug than the more common case of just wanting to avoid throwing
an error for missing values or an API that returns undef in certain
situations.
If an invalid dereference really needs to be "safe", the whole
expression can be wrapped in an eval anyway.
Letting it just be "defined and dereference" is not an 80/20 solution,
but probably more like a 99/1 solution.
-- David
Thread Previous
|
Thread Next