Re: [Rails-core] Attribute query methods and semantics

[Maksym Melnychok]

On Thursday, May 31, 2012 4:50:05 PM UTC+2, Steve Klabnik wrote:
>
> It's not saving a character. It's that !! is programmer talk, and ? is 
> human talk. Ruby prefers human talk. 
>

well your kung-fu beats my kung-fu here

i just don't think post.url? is talking proper human talk to me, i would 
expect answer to that question to be "no, post is not a url" instead i
will get "yes, url attribute is not empty".

> I guess Rafael meant another thing. You have boolean fields in 
> PostgreSQL but someone might prefer to use some old ANSI types, like 
> INTEGER for storing such booleans for some reason. 

i think that first of all this is rather an edge-case that shouldn't force
us to go against least surprise principle

second - this directly goes against Steve's assumption that 

post = Post.new
post.id = 0
assert post.id?

should not fail (it fails because 0 is apparently false.. since when?)

i personally think this smells a lot like PHP and it's non-logical,
generally ugly and wrong truthiness/falseness checks

On Thursday, May 31, 2012 4:50:05 PM UTC+2, Steve Klabnik wrote:
>
> > 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. 
>
> It's not saving a character. It's that !! is programmer talk, and ? is 
> human talk. Ruby prefers human talk. 
>

-- 
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/-/KND68A_wF8sJ.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to 
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en.

Re: [Rails-core] Attribute query methods and semantics

[Maksym Melnychok]

@ 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 <
> rr.ro...@gmail.com> 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  wrote:
>>>
>>>  On Thu, May 31, 2012 at 2:12 PM, James B. Byrne 
>>> 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
>>> .
>>> 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<ht

Re: [Rails-core] Attribute query methods and semantics

[Maksym Melnychok]

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 
>
> On Thursday, May 31, 2012 at 3:28 PM, Jeremy Walker wrote:
>
>
>
> On 31 May 2012 14:23, Sam Oliver  wrote:
>
> On Thu, May 31, 2012 at 2:12 PM, James B. Byrne 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.
> To unsubscribe from this group, send email to 
> rubyonrails-core+unsubscr...@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+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> 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 
>
> On Thursday, May 31, 2012 at 3:28 PM, Jeremy Walker wrote:
>
>
>
> On 31 May 2012 14:23, Sam Oliver  wrote:
>
> On Thu, May 31, 2012 at 2:12 PM, James B. Byrne 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.
> To unsubscribe from this group, send email to 
> rubyonrails-core+unsubscr...@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+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/rubyonrails-core?hl=en.
>  
>  
>  

-- 
You received this message because you 

Re: [Rails-core] Attribute query methods and semantics

[Maksym Melnychok]

my point is about semantics, not truthiness/falseness of values

post.visible? - is asking post object if it is visible because it has
a flag(boolean attribute) named 'visible'

post.url? - is checking if attribute named 'url' is present or not, and
that is exactly what i find confusing because even though 
syntactically it is identical to flag check, semantically this line looks
like we're asking post object if it is a url which makes no sense.

Regards, Max

On Thursday, May 31, 2012 3:12:21 PM UTC+2, byrnejb wrote:
>
>
> On Thu, May 31, 2012 08:58, Maksym Melnychok wrote: 
> > Does anyone else finds attribute query methods semantically confusing? 
> > 
> > Hi, 
> > 
> > Consider this code: 
> > 
> > post = Post.new(:visible => true, :url => "http://com";) 
> > 
> > if post.visible? 
> >   puts "ima visible!" 
> > end 
> > 
> > if post.url? 
> >   puts "ima url! (wait wat? o_0)" 
> > end 
> > 
> > Does this feel right to you? In case with post.url? i read it as "Hey 
> > post object, are you an url?" which is apparently not what the code 
> > will do. 
> > 
> > So it seems like semantically perfect flag checks go together with 
> > totally confusing(for a reader) way of checking whether an attribute 
> > is present or not. 
> > 
> > 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. 
>
> -- 
> ***  E-Mail is NOT a SECURE channel  *** 
> James B. Byrnemailto:byrn...@harte-lyne.ca 
> Harte & Lyne Limited  http://www.harte-lyne.ca 
> 9 Brockley Drive  vox: +1 905 561 1241 
> Hamilton, Ontario fax: +1 905 561 0757 
> Canada  L8E 3C3 
>
>

-- 
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/-/0YtbyF6g470J.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to 
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en.

[Rails-core] Attribute query methods and semantics

[Maksym Melnychok]

Does anyone else finds attribute query methods semantically confusing?

Hi,

Consider this code:

post = Post.new(:visible => true, :url => "http://com";)

if post.visible?
  puts "ima visible!"
end

if post.url?
  puts "ima url! (wait wat? o_0)"
end

Does this feel right to you? In case with post.url? i read it as "Hey post 
object, are you an url?" which is apparently not what the code will do.

So it seems like semantically perfect flag checks go together with totally 
confusing(for a reader) way of checking whether an attribute is present or 
not.

I would generate attribute query methods only for boolean attributes.

Regards, Max

-- 
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/-/YqYSFrZrLWIJ.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to 
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en.

Re: [Rails-core] proc extension problems

[Maksym Melnychok]

yeah, i saw that. i actually found why exactly this problem happens - new 
symbol is generated every time a named scope is called which was defined on 
ActiveRecord::Base

On Thursday, March 22, 2012 3:39:11 PM UTC+1, Sky Faber wrote:
>
> This seems like a known problem with ruby.
>
> I found this old discussion of the issue back from 2008.
>
> http://www.ruby-forum.com/​topic/173699<http://www.ruby-forum.com/topic/173699>
>
> -Sky
> On Mar 22, 2012 4:00 AM, "Maksym Melnychok"  wrote:
>
>> Hi guys,
>>
>> has anyone had problems with this bit of code: https://github.com/**
>> rails​/rails/blob/master/**activesuppo​rt/lib/active_**
>> support/core_​ext/proc.rb<https://github.com/rails/rails/blob/master/activesupport/lib/active_support/core_ext/proc.rb>
>>  ?
>>
>> if i run my application for long enough time i start getting errors like 
>> this:
>>
>> RuntimeError: symbol table overflow (symbol __bind_1328993330_18...)
>>
>> apparently it's because symbols are never GCed and rails generates one 
>> every time this proc extension is used because method names are implicitly 
>> converted to symbols
>>
>> Best Regards,
>> MM
>>
>> -- 
>> 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/-/​mys8W5xHmsUJ<https://groups.google.com/d/msg/rubyonrails-core/-/mys8W5xHmsUJ>
>> .
>> 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<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/-/2lNXHD2mPHUJ.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to 
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en.

[Rails-core] proc extension problems

[Maksym Melnychok]

Hi guys,

has anyone had problems with this bit of code: 
https://github.com/rails/rails/blob/master/activesupport/lib/active_support/core_ext/proc.rb
 ?

if i run my application for long enough time i start getting errors like 
this:

RuntimeError: symbol table overflow (symbol __bind_1328993330_18...)

apparently it's because symbols are never GCed and rails generates one 
every time this proc extension is used because method names are implicitly 
converted to symbols

Best Regards,
MM

-- 
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/-/mys8W5xHmsUJ.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to 
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en.

[Rails-core] mysql connections problem

[Maksym Melnychok]

Hi guys,

recently switched to percona 5.5 and started having "too many connections" 
exceptions

i noticed that exceptions started popping up on the very first slave we 
pushed into the pool so it seems like after redeploy rails does not kill old 
connections to mysql

anyone had such problem before?

i guess options are to: 
- drop inactive connections on mysql side
- handle deploy shutdowns better
- stop using persistent connections

does this even make sense?

-- 
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/-/0w-FWQAxn6EJ.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to 
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en.