On 25 June 2010 08:01, Roger Pack <redmine / ruby-lang.org> wrote:
> Thoughts?
> -rp

+1 This would be handful, I had myself more than once to write it in Ruby.

On 25 June 2010 08:52, Shyouhei Urabe <redmine / ruby-lang.org> wrote:
> Issue #3479 has been updated by Shyouhei Urabe.
>
> The problem on sort-and-freeze menu is that in Ruby sorting function migh=
t differ every time. e.g.
>
> =A0%w"1 70 a3".sort_and_freeze! {|i| i.to_i(16) }.binary_find {|i| i.to_s=
 =3D=3D "70" }
>
> won't work. =A0Yes the example above is a bit impractical, but illustrate=
s the difficulty on it.

I do not exactly understand your example, but from what I understand,
you want to sort using a specific comparison (like #sort_by) (which
the example code from RP do not care of).

Well, in this case the binary search must be done on the Array with
the elements you gave to #sort_by, so basically, this would do a #map
before and then sort (and freeze) and the argument for the search
would then be 070.

I think only binary_{find,search,index}(obj) should be proposed (without bl=
ock).
( I do not see how binary_find {block} could work )

> Though for me, I'm fine with not doing this and allowing for mutable arra=
ys, and just specify that the author must sort them first.
I agree.
It should be specified that a #sort on the Array should change
nothing, then you can safely perform binary_search.

> Array#binary_find (or binary_search, whichever the commiter prefers).

I prefer binary_search, if it returns a boolean, or then binary_find
if it behaves like #find(obj).

B.D.