[ruby-core:36587] Re: [Ruby 1.9 - Feature #4801][Open] Shorthand Hash Syntax for Strings

On Mon, May 30, 2011 at 09:05:04PM +0900, Michael Edgar wrote:
> Since :"#{abc}" is allowed in Ruby, I imagine that any such
> substitute syntax would preserve that property.
> 
> I disagree strongly that Hash, the base class, should special-case
> the behaviors of Strings and Symbols to be equal. It's a hash table,
> like those encountered in any other language, and shouldn't behave
> unlike typical hash tables. Namely h[a] and h[b] look up the same
> value iff a == b (or a.eql?(b), or whichever equality test you use).
> Strings and symbols are never equal.

I though exactly the same thing, until I realized that having keys of
different types in a Hash isn't really part of the general Hash
concept. It is a side effect of Ruby being dynamically typed.

I agree and I wouldn't allow symbols to be equal to strings for keys. I
would take the step further - they shouldn't be both used for keys in
the same Hash - *because* they are two different types. Especially
since they can easily represent one another.

Consider the following:

  { nil =>0, :foo => 1, 'foo' => 2 }

Conceptually, people expect Hash keys to be of the same type, except
maybe for "hacks" like that nil above that can simplify code.

If someone out there in the world actually demands that such a Hash is
valid and that :foo and 'foo' are different keys, you could always wrap
Hash to support that for that single, specialized case.

Otherwise the whole world tries to use HWIA in all the wrong places as
the silver bullet or write complex code to handle "strange" hashes
gracefully. Or use HWIA just to symbolize the keys - "just in case".

In Ruby "foo" + 123 raises a TypeError. Adding a string key to a
symbol-keyed Hash doesn't even show a warning.

I consider hashes with different key types different types of hashes,
that shouldn't even be allowed to merge together without conversion.
This could be useful both in Rails to make the meaning of each HWIA
instance more explicit and for API designers to worry less about how
to process hashes in a robust way.

I think the meaning of symbols and hashes are too similar for such
different types to be allowed as keys in the same Hash instance.

Further more, if the standard Hash didn't allow strings for keys
(another class for current behavior?), the new shorthand syntax would
be even less surprising.

Symbols are recommended in favor of Strings for hashes anyway.

-- 
Cezary Baginski