On Oct 12, 12:53 ¨Âí¬ ¢áòá®ô®èï÷áòä¢ ¼áòá®ô®èï÷®®®Àçíáéì®ãïí¾ ÷òïôåº > > Hi Ara, > > > There is also Stash library (gem install stash -or- gem install > > hashery). > > > One difference between Stash and your Map, is that it uses Strings > > rather then Symbols for keys so they can be garbage collected. > > > Looks like we created these libraries for the same reason. I agree > > with your statement "the ruby container you've always wanted". IMO > > Ruby's built-in Hash should work like this because most of the time > > that's really what we want. A Hash that allows for any type key could > > be separate class instantiated explicitly. > > map does use strings:http://github.com/ahoward/map/blob/master/lib/map.rb#L123 Ah, your example's heavy use of symbols made me think otherwise. Very good. > big differences between the two libs actually: map is *always* > ordered. ¨Âôáóè äïåó îïáððåáò ôï âå®® Stash is a subclass of Hash so it will be as ordered as actual Hash, i.e. 1.8.x no, 1.9 yes. > map also works recursively: > > ruby-1.8.7-p302 > require 'map' > > true > ruby-1.8.7-p302 > m = Map.new > > {} > ruby-1.8.7-p302 > m.update :k => {:a => {:x => 42}} > > {"k"=>{"a"=>{"x"=>42}}} > ruby-1.8.7-p302 > m['k']['a']['x'] > > 42 > > stash does not: > > ruby-1.8.7-p302 > require 'stash' > > true > ruby-1.8.7-p302 > s = Stash.new > > {} > ruby-1.8.7-p302 > s.update :k => {:a => {:x => 42}} > > {"k"=>{:a=>{:x=>42}}} > ruby-1.8.7-p302 > s['k']['a']['x'] > NoMethodError: undefined method `[]' for nil:NilClass > from (irb):14 The error is technically correct. You've assigned a Hash to a Stash as a value, so you can't treat the Hash as if it were a Stash. Otherwise you would never be able to assign an actual Hash as a value. To work correctly one needs to do: s.update :k => Stash[:a => Stash[:x => 42]] I realize automatic conversion might be convenient, but I would be concerned that it could cause issues. I might add a #normalize method though that could descend the Stash and convert all Hash entries and sub-Hash entries to Stashes. I'll give it some thought. Thanks. > so there are definitely big differences between the libs at this > point. ¨ÂõóÆÙÉ® or big differences in our definition of "big"?