From: "Randy W. Sims" Date: 2004-10-09T19:30:09+09:00 Subject: Re: Range behavior (Re: [RCR] New [] Semantics) On 10/9/2004 5:33 AM, Yukihiro Matsumoto wrote: > Hi, > > In message "Re: Range behavior (Re: [RCR] New [] Semantics)" > on Sat, 9 Oct 2004 18:18:12 +0900, "Randy W. Sims" writes: > > |Hmm, I guess I expected Range to be implemented as an ordered set, an > |array. Thus Range#member? would be a quick binary search... > > No. It just hold upper and lower bounds, plus a flag for exclusion of > the last element. Ahh, ok. I didn't realize set was implemented in this way. I can see why you did it: it allows ranges for all types of objects. Very nice. Even with this, It would still be nice if membership could be tested... efficiently. Or at least efficient for the common cases. Range could be special cased for Integers so that a member could be found by calculating elements for a "binary search" (if (((end - start) / 2) > target))... Or better. Some classes could implement an optional method (a mixin interface?), say find_in_range, so that if the method exists for the type of objects in the range it is called for an efficient lookup. If the object does not support the method, it can be done the old way using obj#succ. This is not as kludgy as I've made it sound. There is precedent for this type of implementation in many libraries, including the C++ standard library. This also sort of corresponds to having different iterator types in C++ where some iterators are more powerful/functional than others. Randy.