Gavin Sinclair wrote: > ----- Original Message ----- > From: "Tom Sawyer" <transami / transami.net> > >>i think i understand what your getting at. >> >>but on particulars, there is such a thing as ArrayElement. it is called >>Object. for an array's elements are objects (100% O), while a hashes are >>not. rather they are some sort of syntatical-construct-of-association >>between two objects (nil-O) >> > > > Hashes don't have "elements". They map Objects to Objects. That is their > interface; that is what they are. "Map" is an English-language term used in > documentation to describe the function of a Hash. You can iterate over the > "mappings", and you are given the Objects contained therein. > > Hashes are no more, and no less, object-oriented than Arrays. Hashes do have elements in one sense: h = {:a=>1, :b=>2} h.entries # ==> [[:b, 2], [:a, 1]] Or in the sense that you get ordered pairs when you iterate: h.each { |k,v| ... } The ordered pairs don't "remember" that they came from a hash, but then neither do the array elements you get when you iterate over an array. Syntax preferences aside, why isn't an ordered pair good enough to represent an association between two objects? It's got just enough information (a first and a second element), and it uses the most efficient construct for the job. What more could you want? If you really want the association to remember that it came from a hash, and to "know" that the first element is a key and the second is the value associated with it, you can use a hash with one entry: class Hash def each_assoc each { |k, v| yield({k => v}) } end end h = {:a=>1, :b=>2, :c=>3} h.each_assoc { |assoc| p assoc } class Hash def select_subhash result = {} each_assoc { |a| result.update a if yield a } result end def value if size == 1 values[0] else raise "No unique value" end end end k = h.select_subhash { |a| a.value >= 2 } p k # ==> {:b=>2, :c=>3} This is definitely not as efficient as ordered pairs, but maybe it's clearer if you really want to think in terms of associations.