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 pemungkah (Priest)
on May 31, 2012 at 01:41 UTC ( #973410=note: print w/replies, xml ) Need Help??

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 ...
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; };

    At which point I could basically write

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

    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;

    Ordinary morality is for ordinary people. -- Aleister Crowley
      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.

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

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://973410]
[Corion]: choroba: Yes, but the longer I thought about efficient hashes mapping the event type back to their callbacks, and how to keep them in sync, the more I thought that all that optimization might just not be worth it, even if it's horribly inelegant
[Lady_Aleena]: My biggest problem with hashes at the moment is one with 2,501 keys.
[choroba]: how many event types are there?
[Corion]: Also I found that I can't conveniently weaken an array slot, which also is inconvenient, as I want my one-shots to disappear if the caller discards them
[Corion]: choroba: Currently two or three that my program handles (WWW::Mechanize:: Chrome), but there might be more that become interesting
[Corion]: But I don't expect more than 100 to be active at the same time, so I'm not really sure if there is a not-too-fancy data structure that is maintained with few lines of code where the performance is better than the linear scan ;)
[Corion]: But I should do a mock-up program so that others can see what I'm talking about ;)
[robby_dobby]: Corion: I hope you know all too well that passing around "fancy" datastructures is a recipe for disaster :-)
[robby_dobby]: As in, it's-too-fancy- that-it-will-be- messy-to-handle
[choroba]: bit vectors as keys?

How do I use this? | Other CB clients
Other Users?
Others wandering the Monastery: (13)
As of 2017-05-29 07:58 GMT
Find Nodes?
    Voting Booth?