Beefy Boxes and Bandwidth Generously Provided by pair Networks
Just another Perl shrine
 
PerlMonks  

Re^2: What operator should perl5porters use for safe dereferencing? (->)

by tye (Cardinal)
on Jun 01, 2012 at 06:54 UTC ( #973691=note: print w/ replies, xml ) Need Help??


in reply to Re: What operator should perl5porters use for safe dereferencing? (&-> and ->?)
in thread What operator should perl5porters use for safe dereferencing?

I also strongly support the "make plain -> to be undef-safe" position. I've long found it frankly a design bug that using strict.pm means that $undef->{key} will either 1) silently create a hash or 2) die (depending on often-subtle issues of context).

My preference would be more like: Let me pick how de-ref'ing an undef behaves from 1) silent, 2) warn, or 3) die. Then, depending on my choice, $undef->{key} would pick (depending on context) between these paired choices of behaviors:

  1. a) silently auto-vivify or b) silently return undef
  2. a) auto-vivify with a warning or b) return undef with a warning
  3. a) die or b) die

But, as a transition, it would be great if a future version of Perl 5 had default behaviors of:

  1. w/o 'use strict': a) silently auto-vivify or b) silently return undef
  2. w/ 'use strict': a) silently auto-vivify or b) return undef with a warning

(for extra clarity, 2b would be the only change.)

I almost always 'use strict;' and I almost always want $x = 'y'; $x->{z} to be fatal. But I very often don't want this to die:

sub routine { my( $arg, $opt ) = @_; blarg( $arg ) if $opt->{blargTheArg}; ... }

So I've gotten in the habit of writing ( $opt || {} )->{blarg} (after too many cases of code making it into Production before it ran into a case that resulted in $opt being undef).

So, it will be less work to form a habit of $opt&->{blarg} (or $opt->?{blarg}), but I'd much rather be able to declare that undef-> triggers a warning (in either context) and to have that be the default behavior in the context where the current behavior really just doesn't make a lot of sense.

On a side note, yes, I am aware of the autovivify module. I've long wanted that capability but I have no plans of using that module because the amount and complexity of XS code contained in it seems like a very inappropriate way to implement this feature (except as an experiment / proof of concept before it can be accepted into the 'core' -- which is what I consider this module) and has too high a risk of bizarre failures for the benefit provided, in my experience. I expect that one day the too-much and too-complex XS code of autovivify.xs will be completely replaced by some quite simple 'if' statements that examine 'hint bits' being sprinkled into a few places in Perl's own de-ref-implementing code and then I'll have a 'no autovivify;' that I can feel safe using.

Even better will be if the way that I declare 'de-ref'ing undef in an lvalue context generates a warning' at least can also declare the same (or similar) behavior for rvalue contexts.

- tye        


Comment on Re^2: What operator should perl5porters use for safe dereferencing? (->)
Select or Download Code
Re^3: What operator should perl5porters use for safe dereferencing? (->)
by phaylon (Curate) on Jun 01, 2012 at 13:46 UTC

    I don't think I'd have a big issue with this applying to hash and array refs. but ignoring method calls on undef by default is a big No-no for me. I'd definitely vote for it being a completely separate pragma then.


    Ordinary morality is for ordinary people. -- Aleister Crowley

      Oh, yes. I agree with that.

      - tye        

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others imbibing at the Monastery: (14)
As of 2015-07-01 16:02 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    The top three priorities of my open tasks are (in descending order of likelihood to be worked on) ...









    Results (9 votes), past polls