|
in reply to Re: Use of wantarray Considered Harmful
in thread Use of wantarray Considered Harmful
Array vs. first element is completely useless.
A couple of uses:
- caller
sub c{ return caller(); }
print c();;
main (eval 16) 1
print scalar c();;
main
- each
print each %h;;
a 1
print scalar each %h;;
a
Can you really not see a few other useful uses?
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.
|
Re^3: Use of wantarray Considered Harmful
by dragonchild (Archbishop) on Dec 14, 2008 at 02:45 UTC
|
Whether or not caller and each behave sanely is a separate question. Just because it's in core doesn't mean it's a good idea. Frankly, I think that a subroutine should return one and only one type of entity. It shouldn't return a collection (array, in this case) in one situation and an element (first element, in this case) in another. That leads to serious hard-to-debug issues. This isn't theoretical - it's personal experience speaking.
My criteria for good software:
- Does it work?
- Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
| [reply] |
|
|
Frankly, I think that a subroutine should return one and only one type of entity. It shouldn't return a collection (array, in this case) in one situation and an element (first element, in this case) in another.
But by virtue of how context works in Perl, this issue is actually beyond the control of the subroutine's designer/coder. A subroutine that returns a list will, by virtue of how context works, return a scalar in scalar context (as per ikegami's table above). If some problem is "hard-to-debug" on this basis, it is because the person doing the debugging doesn't understand context -- a situation that is all too frequent among people using Perl, obviously.
Given this environment within which the subroutine designer/coder must work, the key point, as explained by BrowserUK and some others in this thread, is to document, clearly and accurately, what the subroutine does in different contexts, even if this amounts to repeating (briefly) the standard description of Perl's normal behavior (because the next "maintainer" might be some novice who will be seeing this information for the first time). Anyone who tries to use (or debug the use of) someone else's subroutine without reading the docs for it will get no sympathy or special indulgence from me.
As long as context-dependent behavior is properly documented, I don't see a problem with it, and in fact I appreciate the flexibility that it makes available.
| [reply] |
|
|
Frankly, I think that a subroutine should return one and only one type of entity....
That leads to serious hard-to-debug issues. This isn't theoretical - it's personal experience speaking.
In isolation, those sound like wise words, but essentially what you are saying now, is that you think all uses of Perl's context sensitivity are bad and should be deprecated, because you've had trouble with it occasionally. That argument is as fallacious as these, please read the counter arguments.
Context is a unique, integral, important and powerful feature of Perl--and unless things have changed markedly in the last short while--it will be at the core of Perl 6 also.
Speaking Perl without using context, is like speaking English (or French or Dutch or German), without contractions. Possible, but stilted, unnatural, laboured. It's speaking Perl like a foriegner.
Children are using contractions correctly aged 3 or 4 years. Can it really be so hard to get right?
Please, please. Is there no one out there with political weight and a descent level of (natural) language skills that'll help me defend my beloved Perl from the one-idiom-fits-all, OO uniformatists?
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.
| [reply] |
|
|
My level of language skills is in perpetual descent. :) But I'm down with the context. As long as things are well documented I don't mind context sensitivity a bit and it can make hacking easier when applying the same underlying code in different places. E.g.: I find I would rather DBIC return an iterator for use in TT2 and a collection of objects in most CLI stuff so I like the fact that DBIx::Class::ResultSet->search does both. And yes I know about search_rs but it wasn't around in the early days and I like the idiom without just fine.
Update: I see that my use case in agreement with dragonchild above. Surprise, surprise! ...there is really only one good use of wantarray - to return an array or an iterator.
| [reply]
[d/l]
[select] |
|
|
|
|
| |
|
I'm not saying that context sensitivity is bad. I'm saying that switching contexts should be lossless. Lossy context switches lead to hard-to-debug issues.
My criteria for good software:
- Does it work?
- Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
| [reply] |
|
|
| [reply] |
|
|
