+1 to Richard. Keep ? for booleans, get rid of the others and use .blank? and .present? as needed. -- Jarrett Meyer Email: [email protected] Web: JarrettMeyer.com <http://jarrettmeyer.com> Twitter: @jarrettmeyer <http://twitter.com/jarrettmeyer>
On Thu, May 31, 2012 at 9:45 AM, Richard Schneeman < [email protected]> 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 [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. > > > -- > 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.
