From: James Edward Gray II Date: 2009-11-08T06:16:51+09:00 Subject: [ruby-core:26605] Re: HashWithIndifferentAccess to core On Nov 7, 2009, at 2:25 PM, Rick DeNatale wrote: > On Sat, Nov 7, 2009 at 3:14 PM, James Edward Gray II > wrote: >> On Nov 7, 2009, at 1:57 PM, Jeremy Kemper wrote: >> >>> On Sat, Nov 7, 2009 at 10:21 AM, Rick DeNatale >> > >>> wrote: >>>> >>>> So far the argument goes something like this. >>>> Since it seems to be a common use case, perhaps it should be in >>>> Ruby >>>> core. >>> >>> This is a motivating factor. Generally (repeating myself from above) >>> it encapsulates a common pattern: >>> * consume arbitrary key/value data from "outside world," where >>> strings are best choice >>> * work with these data using meaningful keys, where symbols are best >>> choice >>> >>> Such cases are command-line options, database result sets, HTTP >>> header >>> values, etc. Anywhere Ruby works with external data (strings) using >>> some known, consistent semantics (symbols). >> >> I agree with Jeremy that this happens a lot. It's not just Rails. >> In fact, >> we tend to criticize any library that doesn't allow us to use >> String and >> Symbol interchangeably as keys. >> >> There was a presentation on rufus-tokyo at RubyKaigi this year. >> Someone >> mentioned that it didn't do this in the Q and A. The author >> modified his >> library shortly after. >> >> I can name at least three projects I've used similar code in, all >> written >> just this year. I think it's a pretty common occurrence. >> > > > Are there benchmarks showing that implementations such as in > ActiveRecord are bottlenecks? > > Are there benchmarks showing that any of the proposed implementations > really are faster? Is that even a concern? I'm far more bothered by the fact that people have rolled their own almost-identical solution a ton of times now. Shouldn't that be a major criteria for how we should decide to make something standard? James Edward Gray II