From: Rick DeNatale Date: 2009-11-08T05:25:54+09:00 Subject: [ruby-core:26601] Re: HashWithIndifferentAccess to core 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? -- Rick DeNatale Blog: http://talklikeaduck.denhaven2.com/ Twitter: http://twitter.com/RickDeNatale WWR: http://www.workingwithrails.com/person/9021-rick-denatale LinkedIn: http://www.linkedin.com/in/rickdenatale