[ruby-core:26595] Re: HashWithIndifferentAccess to core

I'm not sure that it really makes sense to add any of this to core.

So far the argument goes something like this.

Several important ruby based web frameworks have some form of
HashWithIndifferentAccess class, Rails, Merb and Sinatra have been
mentioned. Did I miss any?

Since it seems to be a common use case, perhaps it should be in Ruby core.

And implementations have been given which either:

    store keys in the hash which are the same type as that given as
the key parameter to WhateverTheHeckWeCallThisThing#[]=
   convert the key to a symbol if it's a string
   convert the key to a string if it's a symbol.

Then the arguments start over what to name it.


So I've just now looked at Merb, Rails and Sinatra to see what's up.

The ONLY difference between Merb and Rails here, as far as I can tell
is the name of WhateverTheHeckWeCallThisThing.  Rails (actually
ActiveSupport) calls it HashWithIndifferent access, Merb (actually the
extlib gem) calls it Mash. Other than the name the code appears to be
identical, including the initial comment:

# This class has dubious semantics and we only have it so that
# people can write params[:key] instead of params['key']
# and they get the same value for both keys.

And what is the implementation? Basically it

   1) overrides the initialize method to convert its keys to strings
after being initialized if the parameter to new is a hash.

   2) overrides Hash#default(key=nil) to efffectively return
self[key.to_s] if the key arg is a symbol and key.to_s is included in
the hash.

   3) overrides Hash#[]=(key,value) to effectively call
         super[convert_key(key)] = convert_value(value)
       where convert_key changes symbols to strings and leaves any
other key alone
       and convert_value converts an ordinary hash value to a
HashWithIndifferentAccess/Mash and leaves anything else alone.  This
is because one of the main uses of this thing is for nested parameters
in a http request.

    4) overrides any other method which takes a key argument to call
convert_key on it before using it.

Sinatra, is much more minimal, as one might expect.  It doesn't have
such a class, rather it defines a  Sinatra::Base#indifferent_hash
method

    def indifferent_hash
      Hash.new {|hash,key| hash[key.to_s] if Symbol === key }
    end

Which simply makes

   indifferent_hash[:a]
return the same value as
  indifferent_hash['a']
if :a isn't a key in the hash.

Sinatra apparently relies on the code which uses these hashes not to
use both a symbol and it's string form together for []=


Personally I think that as implemented in both Rails/Merb and Sinatra,
this is much ado about nothing, It wouldn't really buy much to pull
this code down to core whatever you name it, and if something with
different semantics, such as some of the proposals on this thread was
adopted, it's likely that the frameworks, would ignore it, unless it
were given a name which clashed.

As for the decision made by all three of these frameworks to
consistenly use strings rather than symbols for this, I think it makes
sense.   When I first realized that HashWIthIndifferentAccess did it
this way it didn't make sense to me, since I perceived the motivation
to be performance and one a symbol was interned looking up symbol keys
should be faster since Symbol#hash is O(1), and String#hash is
O(string.length).

But doing it the other way, and using Symbols rather than Strings for
the actual, stored, keys in the hash has a time and space cost,
because every time a String is used as a key in a method, it must be
converted to a Symbol, which requires the equivalent of looking it up
to see if it has already been interned, and making a copy non-gcable.

And taking a laissez-faire approach and storing either strings or
symbols and trying to make them come out the same when the Hash is
accessed, would seem to require additional overhead for each lookup,
as well as introducing ambiguities of specification if both :key and
'key' were used to store in the hash, as I pointed out earlier in this
thread.

To summarize, I'd vote for leaving things in core as they are, and
letting frameworks implement such extensions the way they see fit.
-- 
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