Re^3: RFC: The lightning-rod operator

Sorry but your ideas are not trivial or easy to grasp, so I have to go little by little. =)

I find the desired short cut behaviour to catch undef even more problematic than the rest.

I'd rather prefer a catch_undef { BLOCK } command, because the block would be explicit about what is caught without much explanation.

This can be emulated (at least) with

my $h_b = {};
my $x   = eval {
    use warnings FATAL => 'uninitialized' ;
    $h_b->{velocity}." mph";
} // 'unknown';

print $x;
[download]

I tried to construct some syntactic sugar

sub catch_undef (&) {
    my $code_ref = shift;
    
    eval {
        use warnings FATAL => 'uninitialized' ;
        $code_ref->()
    };
}
[download]

but I'm running into two problems:

1) Obviously pragmas are lexically scoped, I seem to remember there are some obscure tricks to manipulate the warning flags of a coderef (something with $^H ?) but I'm too lazy at the moment.

2) seems to be a bug in the parser, because I get a weird syntax error for

catch_undef { $ref->{velocity} .'mph' } // "unknown";

Too many arguments for main::catch_undef at /tmp/tst.pl line 29, near "// "unknown""

using || instead solves the parsing problem (but not the task)

Cheers Rolf
_{(addicted to the Perl Programming Language and ☆☆☆☆ :)

Je suis Charlie!}

Comment on Re^3: RFC: The lightning-rod operator Select or Download Code

Replies are listed 'Best First'.
Re^4: RFC: The lightning-rod operator by martin (Friar) on Jan 30, 2016 at 17:09 UTC
I'd rather prefer a `catch_undef { BLOCK }` command, because the block would be explicit about what is caught without much explanation. While throwing exceptions or returning early from subroutines are indeed ways of taking short-cuts, it is tricky to get the amount of control I am looking for with existing language constructs. Keep in mind that the suggested operator does not need something that would trigger a warning or error to work, nor would it change the behaviour of similar warnings in the same block. The method calling chain `$a->foo->bar^^->baz->qux`, say, would give us a short-cut after `bar()` but nowhere else. Likewise, the dereferencing chain `$a->[1]->[2]^^->[3]` would autovivify `$a->[1]` but not `$a->[1]->[2]`.	[reply]

Replies are listed 'Best First'.

Re^4: RFC: The lightning-rod operator
by martin (Friar) on Jan 30, 2016 at 17:09 UTC

I'd rather prefer a catch_undef { BLOCK } command, because the block would be explicit about what is caught without much explanation.

While throwing exceptions or returning early from subroutines are indeed ways of taking short-cuts, it is tricky to get the amount of control I am looking for with existing language constructs.

Keep in mind that the suggested operator does not need something that would trigger a warning or error to work, nor would it change the behaviour of similar warnings in the same block.

The method calling chain $a->foo->bar^^->baz->qux, say, would give us a short-cut after bar() but nowhere else. Likewise, the dereferencing chain $a->[1]->[2]^^->[3] would autovivify $a->[1] but not $a->[1]->[2].

[reply]