SQL uses <>, not !=
Blog: http://random8.zenunit.com/ Learn rails: http://sensei.zenunit.com/
It can use IS NOT NULL too
Actually it MUST if you're doing not null queries. <> won't work for
null
Blog: http://random8.zenunit.com/ Learn rails: http://sensei.zenunit.com/
Julian,
Have you done any benchmark testing on using the &: method? I would be curious as to why you say it's slower.
As for uglier - I think that's a personal preference. I personally would never recommend chaining 3 methods together as you did for fear that one would fail causing the infamous "undefined method ... for nil". To my eyes, the map.(&:email) is very clean and easy to read without a bunch of nasty |v| v.email, etc.
I would be curious about performance tests though since you say it's slower. I haven't noticed any major performance hit, but I've never really tested.
-- Josh http://iammrjoshua.com
Julian Leviston wrote:
PMFJI… As I recall, the &:foo notation is a shortcut for Symbol#to_proc so the following code snippets are the same:
def frazzle
self.name.split(//).sort_by{rand}.join(‘’)
end
@stuff.each(&:frazzle)
@stuff.each{|s| Proc.new{|*args| args.shift.send(s, *args)}}
Look in active_support/symbol.rb
So what could make this slower are the facts that 1) you are creating a new anonymous proc for each iteration through the @stuff collection; and 2) you are using the send method to invoke the method referenced by the symbol. Contrast that to:
@stuff.each{|s| s.frazzle}
In this case, the method is being invoked directly, skipping the steps of creating the anonymous proc and then invoking “frazzle” via a send.
So, that’s how I understand it. Now, in the case where you have a dozen users returned and want to list their names next to checkboxes, the performance difference is negligible. It’s the case where you can’t predict the size of the result set that you want to beware of.
Undefine methodcan be caught with rescue 'default' on the end. No
biggie.
Blog: http://random8.zenunit.com/ Learn rails: http://sensei.zenunit.com/