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

Em 30-05-2011 07:58, Cezary escreveu:
> 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<[e-mail]>  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.
> ...

While on the subject, I really wished that hash constructor ({}) was an 
instance of HashWithIndiferentAccess from the beginning in Ruby. 
Actually, it should still be Hash, but should work like 
HashWithIndiferentAccess.

It is very misleading that my_hash[:something] != my_hash['something']. 
Also, I never found any useful on allowing that. Most of times an 
HashWithIndiferentAccess is what you really want.

Changing back to the subject (kind of), in Groovy, here is what happens:

a = [abc: 'some text']; a['abc'] == 'some text'
a = [1: 'some text']; a.keySet()*.class == [java.lang.Integer]

In Ruby, {1: 'some text'} will raise an error. It would be great if it 
allowed numer indexing of hashes with the same syntax.

About {'abc': 'some text'}, it is ok to me to return {:'abc' => 'some 
text'}. But I think this should also be possible:

abc = 'cba'
{"#{abc}": 'some text'} == {:'cba' => 'some text'}

This is also possible in Groovy.

Here are my 2 cents.