Beefy Boxes and Bandwidth Generously Provided by pair Networks
Don't ask to ask, just ask
 
PerlMonks  

Re^2: RFC: The lightning-rod operator

by martin (Friar)
on Jan 23, 2016 at 23:54 UTC ( [id://1153494]=note: print w/replies, xml ) Need Help??


in reply to Re: RFC: The lightning-rod operator
in thread RFC: The lightning-rod operator

Thank you for your comments so far, and thank you for pointing out another technique to avoid autovivification (other than the autovivification pragma on CPAN).

I suppose some of your points will get less of an issue if you do get around to read the rest of the article. In particular, you may rest assured that I don't want to suggest new dereferencing operators.

To the contrary, the lightning-rod or fuse operator I was talking about would make such operators unnecessary.

Replies are listed 'Best First'.
Re^3: RFC: The lightning-rod operator
by LanX (Saint) on Jan 24, 2016 at 21:43 UTC
    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;

    I tried to construct some syntactic sugar

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

    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!

      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].

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://1153494]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others having an uproarious good time at the Monastery: (4)
As of 2024-04-25 16:05 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found