Actually the query attribute method does more than check if the value is present. It is very useful for legacy databases where the user persist boolean values as [0, 1], ["t", "f"], ["true", "false"] and more.
I don't see this being removed from rails or changing your behavior. Also removing it will not decrease the methods count because we still need to generate it for booleans. Rafael Mendonça França http://twitter.com/rafaelfranca https://github.com/rafaelfranca On Thu, May 31, 2012 at 11:17 AM, Rodrigo Rosenfeld Rosas < [email protected]> wrote: > I'd guess methods count is relevant based on this pull request: > > https://github.com/rails/rails/pull/5763 > > Em 31-05-2012 10:49, Maksym Melnychok escreveu: > > absolutely agree with all points. i just didn't know if methods count > argument is relevant at all. imo it's a nice side-effect of proposed > change. > > On Thursday, May 31, 2012 3:45:23 PM UTC+2, richard schneeman wrote: >> >> I'm -1 on a has_* method >> >> If we want to kill ? on non boolean attributes we should encourage >> standard @post.url.blank? and @post.url.present? be used instead. The >> originally proposed change makes sense to me. The question mark character >> adds nice semantics to boolean attributes. I agree it's not clear what >> exactly that would do on non-boolean attributes. Removing the questionable >> methods would help decrease the method count. >> >> Does anyone really need to use: @post.id? >> >> -- >> Richard Schneeman >> @schneems <http://twitter.com/schneems> >> >> On Thursday, May 31, 2012 at 3:28 PM, Jeremy Walker wrote: >> >> >> >> On 31 May 2012 14:23, Sam Oliver <[email protected]> wrote: >> >> On Thu, May 31, 2012 at 2:12 PM, James B. Byrne >> <[email protected]>wrote: >> >> >> > I would generate attribute query methods only for boolean attributes. >> >> I am not sure that I understand your point, but in Ruby anything that >> is neither nil nor false is true. Thus returning the url string, if >> not nil, is the same as saying that it is true but also allows access >> to the actual data without having to send another message. >> >> >> I think Max's point is that "post.visible?" could be read as "post is >> visible?" but "post is url?" carries a different meaning. >> >> >> Maybe have query methods for boolean attributes and prefixed query >> methods for not. e.g. >> post.visible? >> post.has_url? >> >> Or maybe leave the currently methods as they are, but add new prefixed >> methods, with different prefixes for boolean methods, e.g. >> post.is_visible? >> post.has_url? >> >> >> >> Sam >> -- >> 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<[email protected]> >> . >> To unsubscribe from this group, send email to >> rubyonrails-core+unsubscribe@**googlegroups.com<rubyonrails-core%[email protected]> >> . >> For more options, visit this group at http://groups.google.com/** >> group/rubyonrails-core?hl=en<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<[email protected]> >> . >> To unsubscribe from this group, send email to >> rubyonrails-core+unsubscribe@**googlegroups.com<[email protected]> >> . >> For more options, visit this group at http://groups.google.com/** >> group/rubyonrails-core?hl=en<http://groups.google.com/group/rubyonrails-core?hl=en> >> . >> >> >> > On Thursday, May 31, 2012 3:45:23 PM UTC+2, richard schneeman wrote: >> >> I'm -1 on a has_* method >> >> If we want to kill ? on non boolean attributes we should encourage >> standard @post.url.blank? and @post.url.present? be used instead. The >> originally proposed change makes sense to me. The question mark character >> adds nice semantics to boolean attributes. I agree it's not clear what >> exactly that would do on non-boolean attributes. Removing the questionable >> methods would help decrease the method count. >> >> Does anyone really need to use: @post.id? >> >> -- >> Richard Schneeman >> @schneems <http://twitter.com/schneems> >> >> On Thursday, May 31, 2012 at 3:28 PM, Jeremy Walker wrote: >> >> >> >> On 31 May 2012 14:23, Sam Oliver <[email protected]> wrote: >> >> On Thu, May 31, 2012 at 2:12 PM, James B. Byrne >> <[email protected]>wrote: >> >> >> > I would generate attribute query methods only for boolean attributes. >> >> I am not sure that I understand your point, but in Ruby anything that >> is neither nil nor false is true. Thus returning the url string, if >> not nil, is the same as saying that it is true but also allows access >> to the actual data without having to send another message. >> >> >> I think Max's point is that "post.visible?" could be read as "post is >> visible?" but "post is url?" carries a different meaning. >> >> >> Maybe have query methods for boolean attributes and prefixed query >> methods for not. e.g. >> post.visible? >> post.has_url? >> >> Or maybe leave the currently methods as they are, but add new prefixed >> methods, with different prefixes for boolean methods, e.g. >> post.is_visible? >> post.has_url? >> >> >> > -- > 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 [email protected]. > To unsubscribe from this group, send email to > [email protected]. > 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
