From: ahoward Date: 2003-05-28T00:48:28+09:00 Subject: Re: Binary Tree vs. Hash On Tue, 27 May 2003, Robert Klemme wrote: > IMHO that's overly complicating Array. An Array is simply a sequence of > items. Period. on paper - sure. but in reality we have: [ ] new & * + -- << <=> == === [ ] [ ]= | assoc at clear collect collect! compact compact! concat delete delete_at delete_if each each_index empty? eql? fill first flatten flatten! include? index indexes indices join last length map! nitems pack pop push rassoc reject! replace reverse reverse! reverse_each rindex shift size slice slice! sort sort! to_a to_ary to_s uniq uniq! unshift mixins Enumerable: collect, detect, each_with_index, entries, find, find_all, grep, include?, map, max, member?, min, reject, select, sort, to_a *much* more than a sequence of items. what would be the issue if Enumerable was optimized for containers, like Array, which could support random access and binary searches? the same methods would exist - they would simply be faster. admittedly this is less 'general' but optimization for such a heavily used container as the Array makes sense IHMO, espcially when it could be done in such a way to be completely backward compatible while giving a speed increase to practially every ruby program ever written... -a > > To have a sorted array I'd have either > > - a sub class of Array (like SortedArray) that overrides modifying > operations to ensure this invariant (or do it dependend on the flag you > mentioned) or > > - a SortedArray delegating all non modifying calls to an array and > overriding modifying methods. > > I think this is the more component oriented approach. > > Regards > > robert > > -a -- ==================================== | Ara Howard | NOAA Forecast Systems Laboratory | Information and Technology Services | Data Systems Group | R/FST 325 Broadway | Boulder, CO 80305-3328 | Email: ara.t.howard@fsl.noaa.gov | Phone: 303-497-7238 | Fax: 303-497-7259 | ~ > ruby -e 'p % ^) .intern' ====================================