From: Rick DeNatale <rick.denatale@...>
Date: 2010-08-01T01:22:18+09:00
Subject: Re: [].all?{} and [].any?{} Behavior

On Sat, Jul 31, 2010 at 6:07 AM, Robert Klemme
<shortcutter@googlemail.com> wrote:
>
>> For your own usage as long as it doesn't mess up some other code you
>> are using, feel free.
>
> I disagree: IMHO it is a bad idea to change such fundamental behavior
> if only for own code.  This opens the door widely for all sorts of
> bugs and issues.  For example, you get used to #all? doing also the
> emptyness check and get confused when reading other code which of
> course relies on the regular behavior.  Or you forget the "require"
> for the file that changes semantics of #all? and #any? and receive in
> turn subtly bugs which might be hard to track down.  Even worse, you
> use library code that in turn uses #all? or #any? without you knowing
> it and this code suddenly breaks.

Whether or not it's a bad idea, and I tend to agree that it is.  I
said what I did for at least two reasons:

1) I tend not to be puritanical, just as I wouldn't restrict what
anyone wanted to do in the privacy of their own homes unless it was
harmful to others, I think you should be able to write whatever code
you want to under the same philosophy, whether or not it's harmful to
you.

2) Since one of the most useful ways to learn anything in such a way
that you remember and internalize it is to make a mistake and realize
the consequences.
>
>> module Enumerable
>>  def non_vacuous_all?(&b)
>>    !empty? && all?(&b)
>>  end
>> end
>>
>> [3].all? {|element| element == 3 }  # => true
>> [3].all? {|element| element != 3 }  # => false
>>
>> [].all? {|element| element == 3 }   # => true
>> [].all? {|element| element != 3 }   # => true
>>
>> [3].non_vacuous_all? {|element| element == 3 }  # => true
>> [3].non_vacuous_all? {|element| element != 3 }  # => false
>>
>> [].non_vacuous_all? {|element| element == 3 }   # => false
>> [].non_vacuous_all? {|element| element != 3 }   # => false
>>
>> [].any? {|element| element == 3 }   # => false
>> [].any? {|element| element != 3 }   # => false
>>
>> There may be a better name than non_vacuous_all? but I can't think of one.
>
> I'd rather stick with two method calls because it makes crystall clear
> what's happening.  Also, you may first want to check for emptyness and
> if else branch based on that knowledge (or the other way round).  In
> other words: often you may want to separate both checks

Here I completely disagree.  Extracting commonly used code to a well
named method is an essential part of writing and maintaining code.

for example, I see nothing wrong with the sum method which active
support adds to Enumerable

  # Calculates a sum from the elements. Examples:
  #
  #  payments.sum { |p| p.price * p.tax_rate }
  #  payments.sum(&:price)
  #
  # The latter is a shortcut for:
  #
  #  payments.inject { |sum, p| sum + p.price }
  #
  # It can also calculate the sum without the use of a block.
  #
  #  [5, 15, 10].sum # => 30
  #  ["foo", "bar"].sum # => "foobar"
  #  [[1, 2], [3, 1, 5]].sum => [1, 2, 3, 1, 5]
  #
  # The default sum of an empty list is zero. You can override this default:
  #
  #  [].sum(Payment.new(0)) { |i| i.amount } # => Payment.new(0)
  #
  def sum(identity = 0, &block)
    if block_given?
      map(&block).sum(identity)
    else
      inject { |sum, element| sum + element } || identity
    end
  end

Following your argument, this is bad because you might want to use
inject and + separately.

But having such methods doesn't prevent you in the least from using
inject, +, empty?, any? or any other method used to implement a
slightly more abstract extracted method separately.  It does help to
keep your code DRY and to make it more understandable overall since
you don't have to re-understand the effect of the separate invocations
each time you encounter them, as long as you are careful and name the
abstraction in an 'intention revealing' way.

And doing this also enables changing the implementation of the
abstraction without holistic changes to the code.  Yes I know about de
Morgan's rules (I have a CS degree granted by a 1970's era Electrical
Engineering department). Placing the implementation in an abstraction
allows you to do the math proofs/unit testing and refactoring to meet
particular non-functional requirements in one place, which is a good
thing.

I recently was working on a refactoring a large Rails application
taken over from another development shop, which had several nasty bugs
on just this issue of all? returning true for an empty collection.  It
turns out that there are definitely cases where you want to test that
a collection has at least 1 element and that all of the elements have
some property.  Having said that perhaps a better name for the method
might be

   at_least_one_and_all?

That might be a tad long, but I'd rather have a longer but more
intention revealing name, and let one of the several editors I use
deal with keeping my keystroke count down.

-- 
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Github: http://github.com/rubyredrick
Twitter: @RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale