[].all?{} and [].any?{} Behavior

[David A. Black]

Hi --

On Fri, Jul 30, 2010 at 10:49 AM, Rick DeNatale

[].all? {|element| element != 3 } # => true
There may be a better name than non_vacuous_all? but I can't think of
one.


How about #appall? to imply that it is a pessimistic implementation of
#all?

Sorry, hit send by accident.

How about 'every?' for the non-vacuous 'all?'?

If we really need one, that is.

Or maybe "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

 

[Maurizio De Santis]

what about "all_and_not_empty" ?
or maybe: "all_and_when_I_say_all_I_say_all!"

 

[Josh Cheek]

[Note: parts of this message were removed to make it a legal post.]

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_methodall?)
define_method :all? do |emptyval=true,&block|
return emptyval if empty?
old_all.bind(self).call &block
end
end

require 'test/unit'

class NewAllTest < Test::Unit::TestCase
def test_empty
assert ![].all?(false)
assert [].all?(true)
assert [].all?
end
def test_non_empty_no_block
assert ![ nil, true, 99 ].all?(true)
assert ![ nil, true, 99 ].all?(false)
assert ![ nil, true, 99 ].all?
assert [ '', true, 99 ].all?(true)
assert [ '', true, 99 ].all?(false)
assert [ '', true, 99 ].all?
end
def test_non_empty_block
assert [ 1, 3, 99 ].all?( true , &dd? )
assert [ 1, 3, 99 ].all?( false , &dd? )
assert [ 1, 3, 99 ].all?( &dd? )
assert ![ 1, 2, 99 ].all?( true , &dd? )
assert ![ 1, 2, 99 ].all?( false , &dd? )
assert ![ 1, 2, 99 ].all?( &dd? )
end
def test_non_array
assert Hash[*1..10].all? { |key,value| key.odd? && value.even? }
end
end

 

[David A. Black]

Hi --

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_methodall?)
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.


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

 

[Josh Cheek]

[Note: parts of this message were removed to make it a legal post.]

Hi --


On Tue, 3 Aug 2010, Josh Cheek wrote:

What about redefining all? to accept an optional param for what to do when

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.



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

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.

 

[David A. Black]

Hi --

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