From: Cezary <cezary.baginski@...>
Date: 2011-05-30T19:58:58+09:00
Subject: [ruby-core:36578] Re: [Ruby 1.9 - Feature #4801][Open] Shorthand Hash Syntax for Strings

On Mon, May 30, 2011 at 04:21:32PM +0900, Yukihiro Matsumoto wrote:
> Hi,
>
> In message "Re: [ruby-core:36571] Re: [Ruby 1.9 - Feature #4801][Open] Shorthand Hash Syntax for Strings"
>     on Mon, 30 May 2011 16:12:35 +0900, Anurag Priyam <anurag08priyam@gmail.com> writes:
> |Won't that be misleading? I think the OP wants {'key': 'value'} to
> |mean {'key' => 'value}.
>
> I don't disagree here.  But considering the fact that {key: "value"}
> is a shorthand for {:key => "value"}, {"key": "value"} should be a
> shorthand for {:"key" => "value"}.  Besides that, since it reminds me
> JSON so much, making a: and "a": different could cause more confusion
> than the above misleading.
>
> 							matz.

Misleading, yes - but I think this is only a symptom of a bigger
problem.

In Rails projects I can never be sure if the Hash object I am working
accepts symbols (usually), strings (sometimes) or is a
HashWithIndifferentAccess and doesn't matter until a plugin builds its
own Hash from the contents.

The current Hash behavior is the most generic and flexible, but
unfortunately both the most surprising for novices and least
practical, IMHO.

My thought: warn when mixing string and symbol access in a Hash,
because it is most likely an error. It becomes too easy to
accidentally mix external data (String based hashes, though not
always) with code/language constructs (usually Symbol based hashes).

With a warning, you won't guess the syntax wrong and not know
immediately.

I am wondering: is having strings as keys instead of symbols in a Hash
actually useful? Aside from obscure string/symbol optimization cases?

Another idea would be a Ruby SymbolHash, StringHash accessible
from C API that raises when used incorrectly. And methods for
conversion between the two would probably clean up a lot of code.

HashWithIndifferentAccess is cool, but it is only a workaround to
reduce surprise, not to prevent the root cause of it.

With the new syntax we create an extra point of confusion for novices
based on implementation details:

  1. Will I get a Symbol or a String from this syntax?

  2. Should the resulting Hash I pass to an API contain symbols or
  strings or any? What if it changes in the future? How can I get a
  warning or error if I get this wrong?

1) is a problem only because of 2).

Concentrating on getting both correct will cost more productivity than
the flexibility would allow. The current behavior also keeps Hash from
being more consistent with similar structures in other languages (such
as JSON).

These are just thoughts about revising the current Hash behavior to
reflect the changes in the syntax - for the same reasons as the syntax
additions. I don't feel too competent in this area and I am probably
missing a lot of things.

Sorry for the length.

+1 for consistency with :"foo".

--
Cezary Baginski