Clever code often relies on assumptions. Sooner or later, one will break.
I wasn't advocating using the "clever" code. But given that it's oft been cited that "perl is the reference to Perl", justifying not using it on the basis of a well-known reality, not having been explicitly documented is a nonsense.
There are lots of good reasons for not using it, primarily that they have no advantage over the simpler and clearer versions, but the fact that the always-has-been-and-(probably)-always-will-be-and-would-break-half-of-CPAN-if-it-ever-changed behaviour isn't explicitly documented isn't one of them.
Even if they never break, the burden of veryfying assumptions has been added.
You mean like: testing?
Update: Overloaded ops break your claim of always and ever.
Actually it doesn't. The "claim" as you term it, applies to perl, not arbitrary modules.
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] |
always-has-been-and-(probably)-always-will-be-and-would-break-half-of-CPAN-if-it-ever-changed behaviour isn't explicitly documented isn't one of them.
Obviously. That wasn't the point.
You mean like: testing?
Creating a test doesn't help the reader understand there are no hidden motives.
The "claim" as you term it, applies to perl, not arbitrary modules.
I thought we were talking about Perl's relational operators.
| [reply] |
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.
| [reply]
[d/l]
[select] |