From: Brian Candler <B.Candler@...>
Date: 2004-10-05T20:16:24+09:00
Subject: Re: Too Many Ways?

On Tue, Oct 05, 2004 at 07:48:17PM +0900, trans.  (T. Onoma) wrote:
> On Tuesday 05 October 2004 06:05 am, Brian Candler wrote:
> > Errm, well it looks right to me. If you're saying that the range 0...10 is
> > actually the set of integers 0,1,2,3,4,5,6,7,8,9, then 4.3 is not a member
> > of that set; but if you consider it as a continuous range along the number
> > line, then 4.3 is included within that range. And Ruby does indeed
> > recognise the distinction:
> 
> Well, yes, one could look at it that way. But I mean in accordance to the 
> definition as given by Enumerable. From the Pickaxe:
> 
> include? 
>   
>   enumObj.include?( anObject ) -> true or false 
> 
>   Returns true if any member of enumObj equals anObject. Equality 
>   is tested using ==. 

It depends whose definition you think is "correct". Enumerable has a method,
but Range overrides it. It's not documented as such in Enumerable, but maybe
it's intended that 'include?' and 'member?' behave differently where the
object permits it, and only the default lowest-common-denominator case
results in them being the same. Poor documentation is annoying though.

I suppose it could be regularised by:
- removing Enumerable#include? entirely; or
- having a new method for Range (e.g. Range#within_bounds?) which leaves
  include? and member? behaving the same as Enumerable

But from a duck-typing point of view, it might make sense to be able to send
foo.include?(bar) and have the 'optimised' behavior where an object supports
it, falling back to the Enumerable behaviour where not.

It's another example where having two method names for the same thing is
confusing; in this case doubly so because they are documented in one place
as being aliases, but elsewhere they are made to do different things.

Regards,

Brian.