On Wednesday 06 October 2004 05:15 am, Brian Candler wrote:
| On Wed, Oct 06, 2004 at 11:18:50AM +0900, trans.  (T. Onoma) wrote:
| > > Range serves as both continuous and discrete interval of values.
| > > 'member?' treat it as discrete, whereas 'include?' treat it as
| > > continuous.
| >
| > irb(main):001:0> a = 0..2
| > => 0..2
| > irb(main):002:0> a.include?(1)
| > => true
| > irb(main):003:0> a.include?(1.5)
| > => true
| > irb(main):004:0> a = a.to_a
| > => [0, 1, 2]
| > irb(main):005:0> a.include?(1)
| > => true
| > irb(main):006:0> a.include?(1.5)
| > => false
| >
| > :(
|
| Are you saying: get rid of Array#include? and Enumerable#include? (for
| 2.0)?
|

Not at all. This is something particular to a Range so why overload #include? 
with that function? Doing so can cause duck-typing problems. To me member? 
and include? are just different names for the same thing and should stay that 
way.

But if they *are* to differ, then one may very well ask, "why is #include? 
defined in Enumerable?". Take for example, a recent thread on 
#each_with_index. I think the general consensus was to rename it to 
each_with_counter, and relegate each_with_index to the specific classes 
--Array, Hash, etc. It's the same thing here.

It is an interesting design point actually. Is matz' design intention to offer 
two mix-in methods for the same thing, one of them intended for being 
overridden dependent on the context, but not the other? How does one 
"rubber-stamp" that intention? One interesting idea: being able to fix mix-in 
methods as non-overridable.

HTHCMP (clarify my position),
T.