http://qs321.pair.com?node_id=973678


in reply to Re^3: What operator should perl5porters use for safe dereferencing?
in thread What operator should perl5porters use for safe dereferencing?

I'd argue, as you do, that using it in a limited scope makes it not very worthwhile - and that's why I'd use it everywhere. With an added pragma to allow us to warn on messages to NIL, I think it'd be quite reasonable to do that.

Consider: the objective of this is to eliminate code by making message-to-NIL safe. Adding the code to only use it certain places is essentially the same as saying if (defined $foo) and the point was to not need that.

I'd say that if you feel uncomfortable with jumping out of the plane with this chute, so to speak, this approach isn't for you. I've used it a lot in Objective-C programming and I find it really simplifies things, but much as using $_ as the default variable, either it really works for you or it doesn't work at all.

  • Comment on Re^4: What operator should perl5porters use for safe dereferencing?

Replies are listed 'Best First'.
Re^5: What operator should perl5porters use for safe dereferencing?
by phaylon (Curate) on Jun 01, 2012 at 13:27 UTC

    I don't get that using it in a limited scope isn't worthwhile, and I'm not arguing that. I'm actually arguing the opposite. I want normal dereference to fail. This is to replace a common but wordy idiom, not change the language as a whole. I don't see anything safe about ignoring errors in general unless explicitely told to. Which the operator would do.

    I'm not uncomfortable with it, I simply think it's a bad idea for Perl. The explicit operator on the other hand works in a small scope, is explicit and recognizable. Which I'd probably use quite often. "Ignore all my method errors" is something I'd never do.


    Ordinary morality is for ordinary people. -- Aleister Crowley