So there''s been some angst recently about a certain predicate returning 0 and nil rather than true and false. https://github.com/rails/rails/commit/0aa66f0 https://github.com/rails/rails/pull/5329 My point is simply that, if you''re not going to return true, don''t say the method "Returns true" in the docs. 0 is not "true", eve if it is truthy. So I made a docfix pull which fxn closed, but I want some independent eyes on this point, given how mixed up he is in the saga to date. https://github.com/rails/rails/pull/5572 Core team, what say you? -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
On Monday, 26 March 2012 at 5:27 AM, Ben Woosley wrote:> So there''s been some angst recently about a certain predicate > returning 0 and nil rather than true and false. > > https://github.com/rails/rails/commit/0aa66f0 > https://github.com/rails/rails/pull/5329 > > My point is simply that, if you''re not going to return true, don''t say > the method "Returns true" in the docs. 0 is not "true", eve if it is > truthy. > > So I made a docfix pull which fxn closed, but I want some independent > eyes on this point, given how mixed up he is in the saga to date. > > https://github.com/rails/rails/pull/5572 > > Core team, what say you?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. -- Cheers, Koz -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
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. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
First, Michael, the original pull request<https://github.com/rails/rails/pull/5329>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: 1. Always return only true or false. (Nobody''s position, as far as I know) 2. 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) 3. 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? -Ben On Sun, Mar 25, 2012 at 6:35 PM, Xavier Noria <fxn@hashref.com> wrote:> 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. > > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Core" group. > To post to this group, send email to rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to > rubyonrails-core+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/rubyonrails-core?hl=en. > >-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
On 26/03/12 02:13, Michael Koziarski wrote:> 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.This. -- http://jonathanleighton.com/ -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
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. Dave On Mar 25, 10:49 pm, Ben Woosley <ben.woos...@gmail.com> wrote:> 2. 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)-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
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. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Jon, this whole episode was precipitated by the fact that someone''s app was broken by this behavior. See clifton''s pull request here<https://github.com/rails/rails/pull/5329> . On Mon, Mar 26, 2012 at 1:05 AM, dburry <david.burry@gmail.com> wrote:> 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. > > Dave > > On Mar 25, 10:49 pm, Ben Woosley <ben.woos...@gmail.com> wrote: > > 2. 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) > > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Core" group. > To post to this group, send email to rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to > rubyonrails-core+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/rubyonrails-core?hl=en. > >-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
> First, Michael, the original pull request (https://github.com/rails/rails/pull/5329) 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. -- Cheers, Koz -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.