From: "David A. Black" Date: 2010-08-04T06:52:20+09:00 Subject: Re: .any?{} Behavior Hi -- On Tue, 3 Aug 2010, Josh Cheek wrote: > On Mon, Aug 2, 2010 at 5:12 PM, David A. Black wrote: > >> Hi -- >> >> >> On Tue, 3 Aug 2010, Josh Cheek wrote: >> >> What about redefining all? to accept an optional param for what to do when >>> empty? It doesn't change default behaviour, but lets you get your >>> preferred >>> behaviour out of it. (note this only works on 1.9, because of how procs >>> take >>> params in 1.8) >>> >>> >>> module Enumerable >>> old_all = instance_method(:all?) >>> define_method :all? do |emptyval=true,&block| >>> return emptyval if empty? >>> old_all.bind(self).call &block >>> end >>> end >>> >> >> You're working a bit too hard there; you can just do: >> >> module Enumerable >> alias old_all all? >> def all?(emptyval=true, &block) >> return emptyval if empty? >> old_all(&block) >> end >> end >> >> with no need for the round trip to the method object and back. >> >> But I think overall it might be even easier just to call empty? :-) I'm >> also not a fan of Boolean arguments. I never remember what they mean. >> > I did it that way based on the observations at this blog > http://blog.jayfields.com/2006/12/ruby-alias-method-alternative.html but I > guess if you're working by yourself, you will know you did it and not have > collision issues, and if you're working with a team, you would probably not > be redefining Enumerable#all? so alias is probably a much better choice. The blog post makes the motivation clearer to me -- thanks. The Enumerable#all example is (I hope :-) just hypothetical; I definitely wouldn't advocate overriding it at all. David -- David A. Black, Senior Developer, Cyrus Innovation Inc. The Ruby training with Black/Brown/McAnally Compleat Philadelphia, PA, October 1-2, 2010 Rubyist http://www.compleatrubyist.com