Re^4: Use of wantarray Considered Harmful

[BrowserUk]

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?

[Your Mother]

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.

[BrowserUk]

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.

[dragonchild]

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.

[dragonchild]

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.

[Anonymous Monk]

Your right Brow sir Uk