Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things
 
PerlMonks  

Re^6: Use of wantarray Considered Harmful

by BrowserUk (Pope)
on Dec 14, 2008 at 09:50 UTC ( #730266=note: print w/replies, xml ) Need Help??


in reply to Re^5: Use of wantarray Considered Harmful
in thread Use of wantarray Considered Harmful

Surprise, surprise! ...there is really only one good use of wantarray - to return an array or an iterator.

Hm. I agree that is a very good use case. And by itself, it justifies having context sensitivity. But once you have context sensitivity, it is certainly not the only good use case.

Perhaps my most often used built-in examples are localtime; m//g; readline (often as not as the diamond operator). These return a scalar or list.

Another contention above is: "a subroutine should return one and only one type of entity.". Not only does the "iterator or array" assertion flatly contradict this--an iterator is either a scalar or a coderef; but certainly not an array--but from another view point, a subroutine can either return a list, or a scalar (or nothing). And a scalar is just a single element list. And nothing is the empty list.

That makes the return always of one type: a list of 0, 1, or many elements. Sounds pretty CS to me.

Context only becomes a problem when you stop thinking in Perl and start thinking in terms of some other language, or overarching paradymn. Just as Great Circle math becomes a problem if you are a flat earther.


Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.

Replies are listed 'Best First'.
Re^7: Use of wantarray Considered Harmful
by dragonchild (Archbishop) on Dec 19, 2008 at 16:01 UTC
    What I meant by that was that the subroutine should always return the same information - changing context should be lossless. Hence, an array vs. an iterator (or an arrayref). But, not an array vs. the first element.

    As for your examples: localtime does array vs. joined array. That's on the border of acceptable. The diamond operator and readline are lossless - they are their own iterators (which is another rant for another day). m//g always returns a list - what you do with that list is your decision.


    My criteria for good software:
    1. Does it work?
    2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
      What I meant by that was that the subroutine should always return the same information - changing context should be lossless. Hence, an array vs. an iterator (or an arrayref). But, not an array vs. the first element.

      I still think you are missing the point. The assumption is that in the latter case, that the routine must be calculating the entire array and then discarding most of the data in a scalar context. But that just isn't the case.

      In the case of the each sub the routine can detect the scalar context and avoid a potentially costly determination of the value if the user only wants the key. That's a 50% or potentially much higher optimisation. And that for a sub that returns just a 2 element list:

      sub each { ... return wantarray ? ( getKey(...), getValue(...) ) : getKey(...); }

      For a sub like caller, if the user only wants the calling package name--which probably accounts for 90% of uses--then detecting scalar context to avoid walking a complex AST to gather the rest of the information that the user would only then discard, is again, a very useful optimisation. Think about something like Moose which needs to detect the caller package a lot, and how much more slowly it would run if caller went through the process of gathering all the 11 possible values, everytime the calling code just need the first.


      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.

      m//g always returns a list - what you do with that list is your decision.

      Aside from the fact that it's impossible for an operator to return a list in scalar context, m//g behaves quite differently in scalar and in list context.

      It can act as an iterator (which I think you consider as being the same as a list for the discussion):

      while (/.../g) { ... }

      But it's not an iterator in this tokenizer:

      /\G( ... )/g or die; my $token1 = $1; /\G( ... )/g or die; my $token2 = $1; ...

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://730266]
help
Chatterbox?
[Discipulus]: Corion are you would able to realize such thing? O_O
[Corion]: In the same vein I have a script that automates Firefox to enter some data into another system. It's not faster than the people using the script if they were to do it manually, but they prefer not having to check the data and not having typos when ...
[Corion]: ... entering the data
[Corion]: Discipulus: I don't know whether I could really do that, but the init process itself mostly launches other processes, and the whole startup is just following a path of dependencies and making sure they are all running. Which basically is what ...
[Discipulus]: when at work my time is (temporarly) owned by the firm, so i do not care (coworkers whatch movies.. I code Perl)
[Corion]: ... make already does, except for files instead of programs. But maybe with some /proc hackery, that could be eliminated and one could use plain make :-D
[choroba]: systemd just makes is asynchronous
[choroba]: so, make -j
[Corion]: Discipulus: Yeah - but when writing Perl to save time (instead of having fun), it helps to look whether you're actually saving time ;) Why spend 5 minutes doing manually what you can spend three years automating? ;)
[Corion]: choroba: Oh, yeah :-D

How do I use this? | Other CB clients
Other Users?
Others lurking in the Monastery: (7)
As of 2017-07-27 09:32 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    I came, I saw, I ...
























    Results (408 votes). Check out past polls.