Dave Thomas wrote:

# Mark Slagell <ms / iastate.edu> writes:
#
# > At first glance, I like the idea of any/all -- they seem to have broad
# > applicability.
# >
# > Alternative name suggestions: "any_satisfies" and "all_satisfy" are
# > more descriptive but a bit long - maybe just adding question marks
# > would be good: "any?" and "all?".
#
# I like any? and all? We might want to make 'exists?' an alias for
# 'any?', and 'none?' == '!all?'.

And 'some?' for 'any?' as well, to complement 'none?'.

# Could I also vote for 'count'
#
#     thing.count { |i| i > 3 }

Yes, we'll count that as a vote. :-)  Make that two votes.

# Then... do we add it to Enumerable, so do we put it in a separate
# library
#
#    module Enumerable
#       include Existential
#
#   end
#
# Why do this? Two reasons. First, it avoids cluttering Enumerable
# (that's a poor reason). The second is that we get to play with it
# before committing changes to the interpreter.

Which means that people will likely play with a substantially wider range
of potentially useful things than otherwise, which is desirable for
maximally improving Ruby.

# I'm thinking that we
# implement it in Ruby, and put the source in lib/. We then see if it is
# useful and if it is actually used. If so, and if the performance hit
# of implementing it in Ruby proves to be too great, we can then move it
# in the the C source.
#
# In general, I'm thinking that this is a good way to do all kinds of
# new features: implement them first in Ruby before adding bulk to the
# interpreter.

Conrad Schneiker
(This note is unofficial and subject to improvement without notice.)