Creating a test doesn't help the reader understand there are no hidden motives.
Don't restrict "testing" to "creating a test". When I don't understand something I read in a piece of code, I run a few tests until I do.
Beyond that, I'm not going to spend time defending idioms that have no advantage over the simple alternative. Not even a golfing advantage. Once you remove the common elements, you get ?: vs. [,]->[] vs. (,)[]
With no golfing advantage; no performance advantage; no evaluate the arguments once advantage; and no clarity advantage. I see lots of good reasons for eshewing the idioms, without reference to an 'it ain't never going to happen' justifiction.
I thought we were talking about Perl's relational operators.
A couple of examples from IO::All's pod:
io('file.txt') > $contents;
$contents < io 'file.txt';
I don't think that there is any way that you could claim those to be examples of "Perl's relational operators"?
Even if the overloading module deals with numerical quantities and overloads those symbols to performs comparisons of those quantities, if its author chooses to forgoe tradition, example and existing practice and return, say, "0 but true" instead of 1, then I don't think that you can lay the blame for that at Perl's door.
Obviously. That wasn't the point.
You say that the point of stating "<= is not documented to return 1 when true." is not that the " behaviour isn't explicitly documented". Then perhaps you could explain what the point of the statement was?
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.
|