@ Rafael Mendonça França
legacy databases storage must be concern of corresponding database
adapter, if a field is of boolean type, whatever that means on storage
level of particular database, that field must be treated as boolean in rails
on the model level.
i'm not suggesting to drop such functionality for boolean attributes, only
for non-booleans where #{attribute}? literally makes no sense when you
read it.
methods count would be decreased because rails would generate query
method only for boolean attributes.
@ Steve Klabnik
syntactically you are correct
but if we decide that there doesn't have to be semantical contribution to
your code from using attribute query methods then #{attribute}? is just
a shortcut for !!#{attribute} - so why do we need it in the first place?
saving 1 character is weird goal here.
if on the other hand we want query methods to provide semantics then
there is obvious conflict with non-boolean fields as semantics there are
different.
On Thursday, May 31, 2012 4:30:20 PM UTC+2, Rafael Mendonça França wrote:
>
> 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.
>>
>
>
On Thursday, May 31, 2012 4:30:20 PM UTC+2, Rafael Mendonça França wrote:
>
> 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 view this discussion on the web visit
https://groups.google.com/d/msg/rubyonrails-core/-/Wse1BYmm5u0J.
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.
