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

Yes, and that's an alternative that's been proposed (by me and independently by others). The consensus is that it could be done using autobox. That's my personal preference, with the option to turn off a warning for it: 
  $z = $not_defined->arbitrarymethod()
  Method not called at ...

[download]
I personally think that's preferable to a whole new operator; the idea is to make it work in much the same way that sending messages to nil does in Objective-C: it does nothing, and returns nil (which equivalences to 0 in numeric context). For Perl, it'd do nothing and return undef (in list context it'd return an empty list).
  • Comment on Re^2: What operator should perl5porters use for safe dereferencing?
  • Download Code

Replies are listed 'Best First'.
Re^3: What operator should perl5porters use for safe dereferencing?
by phaylon (Curate) on May 31, 2012 at 14:58 UTC

    The thing is, I would want to use this in a scope as limited as possible. Which means I would end up with: 

      my $object = $other_object->get_object;
  my $result = do {
    use safederef;
    $object->possible_method;
  };

    [download]

    At which point I could basically write 

      my $object = $other_object->get_object;
  my $result = $object ? $object->possible_method : undef;

    [download]

    Which would mean we'd end up with a best-case scenario where the traditional way needs less code to provide the same. Compare this to: 

      my $result = $other_object?->get_object?->possible_method;

    [download]
    Ordinary morality is for ordinary people. -- Aleister Crowley
[reply]
[d/l]
[select]
      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.

[reply]

        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
[reply]
Re^3: What operator should perl5porters use for safe dereferencing?
by Anonymous Monk on Jun 08, 2012 at 19:11 UTC
    I've been using Perl for a while and with Perl's 'do what you want' it would seem that there shouldn't be a new operator. Returning undef seems fine with a warning
[reply]
      I think it's mostly getting used to the different semantics. I love how much more compact the code is in Objective-C when I don't have to worry about sending messages to undef. But I can equally understand the desire to have that throw an exception. The "I'll add a new operator to provide this" seems like a harder way to have both options - but it does specifically call out "In this case, I am explicitly deciding to do safe deref", so...

      I'l try to get something working so it can at least be tried.

[reply]

In Section Past Polls