Rails core - Aug 2009 - ActiveSupport: alternative Block execution on empty Enumerable

i made a suggestion for this within lighthouse.

Pratik said: "This looks interesting. But I''m not sure if this
pattern
belongs to the core or not. You should probably spark a discussion in
the core ML - http://groups.google.com/group/rubyonrails-core"

The Subject can be found here / with a few Pros and Cons...

http://blog.sponagl.de/2009/1/23/alternative-block-execution-on-empty-enumerable

or - the "code only" version:

module Enumerable
  def else(&block)
    self.respond_to?(''empty?'') && self.empty? ? yield
: self
  end
end

Best
Paul

I like it. Is there a ticket and patch that I can verify and add my +1?

Eloy

On Aug 6, 2009, at 10:10 AM, Paul wrote:
>
> i made a suggestion for this within lighthouse.
>
> Pratik said: "This looks interesting. But I''m not sure if
this pattern
> belongs to the core or not. You should probably spark a discussion in
> the core ML - http://groups.google.com/group/rubyonrails-core"
>
> The Subject can be found here / with a few Pros and Cons...
>
>
http://blog.sponagl.de/2009/1/23/alternative-block-execution-on-empty-enumerable
>
> or - the "code only" version:
>
> module Enumerable
>  def else(&block)
>    self.respond_to?(''empty?'') && self.empty? ?
yield : self
>  end
> end
>
> Best
> Paul
>
>
> >

What about using Object#try and avoiding the explicit &block argument?This
avoid to instantiate a Proc object *for each* method execution, if any block
isn''t passed and the enumerable is empty the VM will raise a
LocalJumpError.

module Enumerable
  def else
    self.try(:empty?) ? yield : self
  end
end

Please look at this benchmark (http://gist.github.com/163274) my
implementation is exactly 4x faster ;)

Cheers,
Luca
-- 
lucaguidi.com
twitter.com/jodosha

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Similar discussion from an older ticket:
https://rails.lighthouseapp.com/projects/8994/tickets/1815-patch-add-or_if_blank-to-object


On Thu, Aug 6, 2009 at 8:38 AM, Luca Guidi <guidi.luca@gmail.com> wrote:
> What about using Object#try and avoiding the explicit &block
argument?This
> avoid to instantiate a Proc object *for each* method execution, if any
block
> isn''t passed and the enumerable is empty the VM will raise a
LocalJumpError.
>
> module Enumerable
>   def else
>     self.try(:empty?) ? yield : self
>   end
> end
>
> Please look at this benchmark (http://gist.github.com/163274) my
> implementation is exactly 4x faster ;)
>
> Cheers,
> Luca
> --
> lucaguidi.com
> twitter.com/jodosha
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Yeah creating a proc every time isn''t needed and much cleaner this  
way. I do think that it''s better to use #blank? as was used in
Ryan''s
patch. Still waiting for that ticket :)

Eloy

On Aug 6, 2009, at 2:44 PM, Ryan Angilly wrote:
> Similar discussion from an older ticket:
https://rails.lighthouseapp.com/projects/8994/tickets/1815-patch-add-or_if_blank-to-object
>
>
> On Thu, Aug 6, 2009 at 8:38 AM, Luca Guidi <guidi.luca@gmail.com>  
> wrote:
> What about using Object#try and avoiding the explicit &block argument?
> This avoid to instantiate a Proc object *for each* method execution,  
> if any block isn''t passed and the enumerable is empty the VM will
> raise a LocalJumpError.
>
> module Enumerable
>   def else
>     self.try(:empty?) ? yield : self
>   end
> end
>
> Please look at this benchmark (http://gist.github.com/163274) my  
> implementation is exactly 4x faster ;)
>
> Cheers,
> Luca
> -- 
> lucaguidi.com
> twitter.com/jodosha
>
>
>
>
> >

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Ugh, scrap that, I need sleep.

On Aug 6, 2009, at 2:50 PM, Eloy Duran wrote:
>  I do think that it''s better to use #blank?

Ticket: https://rails.lighthouseapp.com/projects/8994/tickets/1950

Mike

On Aug 6, 2009, at 7:50 AM, Eloy Duran wrote:
> Yeah creating a proc every time isn''t needed and much cleaner this
> way. I do think that it''s better to use #blank? as was used in  
> Ryan''s patch. Still waiting for that ticket :)
>
> Eloy
>
> On Aug 6, 2009, at 2:44 PM, Ryan Angilly wrote:
>
>> Similar discussion from an older ticket:
https://rails.lighthouseapp.com/projects/8994/tickets/1815-patch-add-or_if_blank-to-object
>>
>>
>> On Thu, Aug 6, 2009 at 8:38 AM, Luca Guidi <guidi.luca@gmail.com>
>> wrote:
>> What about using Object#try and avoiding the explicit &block  
>> argument?
>> This avoid to instantiate a Proc object *for each* method  
>> execution, if any block isn''t passed and the enumerable is
empty
>> the VM will raise a LocalJumpError.
>>
>> module Enumerable
>>   def else
>>     self.try(:empty?) ? yield : self
>>   end
>> end
>>
>> Please look at this benchmark (http://gist.github.com/163274) my  
>> implementation is exactly 4x faster ;)
>>
>> Cheers,
>> Luca
>> -- 
>> lucaguidi.com
>> twitter.com/jodosha
>>
>>
>>

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Just updated the benchmark (http://gist.github.com/163274), tried to solve
the issue using #any? instead of #try, but isn''t fast for filled
arrays:
module Enumerable
  def else
    not any? ? yield : self # don''t try this at home
  end
end

Luca
-- 
lucaguidi.com
twitter.com/jodosha

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

much better - thank you!

On Aug 6, 2009, at 4:10 AM, Paul wrote:
> module Enumerable
>  def else(&block)
>    self.respond_to?(''empty?'') && self.empty? ?
yield : self
>  end
> end

Wouldn''t this method be better named "ifempty"? If you call
it "else"
it makes me wonder where the other part of the clause is? Certainly it  
reads nicely in expressions like this:

results.each do |x|
   puts x
end.else do
   puts "none found"
end

But each isn''t exactly an if statement. I can guess what it means in  
the context above, but it doesn''t read right.

And what if you wanted to use it on its own?

results.else do
   puts "none found"
end

In the case above it makes little sense. "ifempty" seems to read a  
little better.

--
John Long
http://recursivecreative.net

... or perhaps even or_if_blank.   :-)


Ryan

On Thu, Aug 6, 2009 at 11:02 AM, John W. Long <me@johnwlong.com> wrote:
>
> On Aug 6, 2009, at 4:10 AM, Paul wrote:
> > module Enumerable
> >  def else(&block)
> >    self.respond_to?(''empty?'') && self.empty?
? yield : self
> >  end
> > end
>
>
> Wouldn''t this method be better named "ifempty"? If you
call it "else"
> it makes me wonder where the other part of the clause is? Certainly it
> reads nicely in expressions like this:
>
> results.each do |x|
>   puts x
> end.else do
>   puts "none found"
> end
>
> But each isn''t exactly an if statement. I can guess what it means
in
> the context above, but it doesn''t read right.
>
> And what if you wanted to use it on its own?
>
> results.else do
>   puts "none found"
> end
>
> In the case above it makes little sense. "ifempty" seems to read
a
> little better.
>
> --
> John Long
> http://recursivecreative.net
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---