Beefy Boxes and Bandwidth Generously Provided by pair Networks
Problems? Is your data what you think it is?

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

by tye (Sage)
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 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        

Replies are listed 'Best First'.
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?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://973691]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others musing on the Monastery: (8)
As of 2017-02-26 09:34 GMT
Find Nodes?
    Voting Booth?
    Before electricity was invented, what was the Electric Eel called?

    Results (372 votes). Check out past polls.