In the absence of a particular bug which this difference causes, one not caused by a theoretical C programmer who writes != 0, then the entire discussion has already consumed more time than is justified by such a minor distinction.
I am only going to say here that I wouldn't have accepted that doc patch on Friday. The rationale and opinion about your proposal is independent of the other threads.
First, Michael, the original pull request was opened by @clifton, whose app was broken by this change.
Second, to lay out the question as I see it: how should predicates behave? They can either:
Always return only true or false. (Nobody’s position, as far as I know)
Generally return true/false, but may return other values instead if there is a good reason to, such as the ability to conveniently provide pertinent information (The core lib’s position, my position and the position of basically everyone else AFAICT)
Return anything for any reason or no reason, so long as results are truthy and falsey at the right times (fxn’s position, and maybe tenderlove’s position)
I think it’s nifty that #nonzero? returns the number, or that #world_readable? returns the permissions bits. But to have #xhr? returns 0 rather than true, for no articulable reason, as a random side-effect of the implementation - well basically it hurts my brain.
Finally, I think the interest in this change is primarily driven by the nature and content of the response.
When valid pull requests and attempts at compromise are closed for reasons which are clearly unpersuasive to a significant number of rubyists, by the one core member who created of the issue, it makes me wonder. Shouldn’t we just settle this by openly choosing the best of the 3 options above, or some as-yet unarticulated option?
Thanks Ben for the thoughtful words. I agree wholeheartedly.
The way this issue is being handled illustrates why many rails lovers
originally resorted to writing Merb, which was then borrowed from to
create Rails 3 when the rails guys finally came to their senses. It
also illustrates why one Russian guy recently got so frustrated at a
few core guys refusing to listen to the masses, that he 0day hacked
the rails repo, just to prove a point about why a certain decision was
so evil for rails app security. Please stop making the masses of
people who care about rails resort to such tactics to be heard.
It seems, the only reason for all the bike shedding is that someone actually went through the trouble of reverting a commit and explaining why, as if that harmless cleanup for some obsessive compulsive folks out there actually did matter, and is worth a discussion. The revert validated the flame. No?
Max
P.S. Just pointing this out, don't care about the issue itself.
First, Michael, the original pull request was opened by @clifton, whose app was broken by this change.
The author admits that that change is bad form anyway. I agree it’s mildly annoying however unless we take position 1 in your list then there’s always going to be stuff that breaks in his ‘serialize to json’ case. The two languages are different and these things will happen.
When valid pull requests and attempts at compromise are closed for reasons which are clearly unpersuasive to a significant number of rubyists, by the one core member who created of the issue, it makes me wonder. Shouldn’t we just settle this by openly choosing the best of the 3 options above, or some as-yet unarticulated option?
The ‘a significant number of rubyists’ argument is a slippery slope. You can drum up an internet army to bitch and moan about any change you’d like here, and there’s always someone who thinks that it’s a frigging TRAVESTY that the bike shed is blue.
To put it simply, there’s no place to draw the line with niggly little pull requests like this and to consume the limited time of the community of contributors going back and forward over this is entirely. This thread has already brought out some nutjob with a laughably incoherent view on history and an axe to grind. These long bikeshedding threads serve only to feed the madmen with nothing better to do. The negative side effects to the community of encouraging this kind of thing FAR outweighs the potential benefits of fixing ‘just this one thing’.
I’m sorry that someone’s app broke, and I’m sorry that tickets were hastily closed in a way that came across as hostile or dismissive. But to dwell on this further is worse.