From: Trans Date: 2007-06-26T03:11:15+09:00 Subject: Re: Behaviour of Enumerables reject vs. select mixed into Hash On Jun 25, 9:47 am, dbl...@wobblini.net wrote: > Hi -- > > > > On Fri, 22 Jun 2007, Trans wrote: > > >> On 6/21/07, Rob Biedenharn wrote: > > >>> What no one seems to have (directly) focussed on is that Hash#each > >>> gives two-element [k,v] arrays back as the content. > > > That's right. And if you wanted things to be "just ducky", it would > > have to give only the v. I've actually argued in favor of that before, > > b/c it's not unreasonable to see that an Array index is like a Hash > > key. So, for a full parallel we'd need to see something like: > > > {:x=>'m'}.each { |v| v #=> 'm' > > > ['m'].each { |v| v #=> 'm' > > > {'x'=>'m'}.each_assoc{ |a| a #=> ['x','m'] > > > ['m'].each_assoc{ |a| a #=> [0,'m'] > > > One could easily argue that an Assoc class would be quite useful here, > > rather than relying on 2-element Array to fulfill the roll. With that > > in hand, it would re easy enough to add the #<< method for enumerable > > construction. > > I don't think there's any reason to expect just the value when > iterating through a hash. In fact if you're using a hash, you > probably have a reason for storing data that way and iterating > pair-wise seems logical to me. > > I think it's a question of how one looks at the underlying types or > behaviors. I don't think the language has to converge around the > smallest possible number of interfaces. You can look at it the other > way around. It's useful (extremely) to have hashes, and to iterate > over them in pairs. Enumerable is one way to help introduce that > construct into the language -- not a one-stop-shopping hash > implementation, but helpful. > > If we then find fault with hash behavior because it's not in line > precisely with other enumerables, that's a kind of reverse logic; it's > a way to talk the language out of having something useful, which I > don't think is a good idea. Enumerable not only allows but requires > that each class implement #each, and there's no constraint that every > enumerable class has to yield exactly one value at a time. I'd want > to see more concrete evidence that having hashes and arrays behave > differently is really creating problems before wanting to normalize > them around one construct. I don't necessarily disagree with you. I was following the natural conclusion of one possible perspective, namely, that the a hash key corresponds to the array index. It's one possible way to fix the the issue posited by the thread. And yet, if our hashes were in fact ordered, as some have asked for, this assumption would fail. So I'm not actually for it, but it does offer some contrast. Consider the order hash perspective. We have an index, plus a key and a value. So in this case, what exactly are we enumerating? We say "pairs" as if it is something, but Ruby doesn't really have such a thing. The closest we come to is a 2-element array. Perhaps that is enough, but it's hardly embraced as such. We see it only in the iteration of #each _if_ we use a single var. There is no Hash.new([:a,'x'],[:b,'y']) or hash << [:a,'x'], etc. If there were, I think this issue wouldn't exist. I think Enumerable would a little more robust, and we could expect that a Hash be returned from #select. While the 2-element array covers the need, maybe not so much the want, and we might even consider a real Pair object: pair = (:a => 'x') pair.key #=> :a pair.value #=> 'x' If we don't take this perspective (irregardless of an actual Pair class, or not) I don't see any good reason to have Enumerable included in Hash. Just define the desired "enumerating" methods on Hash itself --just like #reject. But personally, I'd prefer we get Enumerable right. And while were on the subject --it seems that's exactly what we're doing with String. I hear that String will no longer be Enumerable in future Ruby. I really just don't get this. What's so problematic with a default "view" of strings as ordered-sets of characters? All it requires is the proper definition of #each. Clearly the way things are now is broken. But does this really require us to scrap String enumerablity all together? At the very least, how terribly inefficient it will be to have to convert an string to an array of characters (eg. bunches of little strings), just to iterate over it. T.