Issue #7797 has been updated by rosenfeld (Rodrigo Rosenfeld Rosas).


shevegen (markus heiler) wrote:
> > Since #7792 has been rejected (although I don't really understand the
> > reason except people being afraid of changing I guess)
> 
> Several reasons were given to you. I do not understand why you try to
> "summarize" them all by stating that "people are afraid of change".

The only real reason I remember people mentioning is the performance thing and how they are different internally. It shouldn't really matter to the language design its implementation details (if they are different internally or not, for instance). And for the performance argument I really believe symbols cause more harm than good to the overall performance given all conversions that it will require in most code bases (even if you don't do that directly it is likely that you rely on some gem that will do that).

> If ruby would get rid of symbols, the language would be simnpler for
> newcomers. But why have symbols been exposed at the ruby-language
> level at all?

Have no idea! My suspect is that someone thought: "hey maybe it would be a great idea if we could optimize some constant strings - we could create a symbol for that - hey, look at my micro-benchmarks, it really is a great idea!".

> That's right, because they are simply more efficient than Strings.

On micro-benchmarks I agree they may do some small difference. On real world-case apps though I'd suspect its presence is actually causing code to perform worse.

> What you basically tried in your earlier proposal was to change
> ruby to a completely different language...

Why do you think that removing symbols would change Ruby in a fundamental way? I believe 99.9% of all Ruby code would still work without any changes if :symbol was the same as 'symbol'.freeze.

> This is a huge conceptual change

This is your opinion. I don't agree.

> ..I myself would rather like if this new syntax would
> not have been added at all. I dont like it, and even
> though you save a few keys

The problem is not saving keys for my particular case. It is pretty natural to me when I'm typing to find the comma (:). Greater than signals (>) and, specially the equals (=) symbol require much more effort, which makes a big difference when you're creating a hash with many keys. Those two symbols are also very far from each other.

> I do agree with you that it is annoying that symbols
> and strings can be used for hash keys. When I write
> ruby code, I always have to ask myself whether I 
> want to use a symbol or a string as key.

That is exactly the reason why I created this ticket.

> I do not however see how your proposal makes THIS 
> very decision any simpler.

Simple, you don't have to worry about it anymore. Just don't think. If you've typed a symbol, that's fine. A string instead? No problem. Both should work interchangeable:

h = {a: 1, 'b' => 1}
h['a'] == h[:b] # == 1
----------------------------------------
Feature #7797: Hash should be renamed to StrictHash and a new Hash should be created to behave like AS HashWithIndifferentAccess
https://bugs.ruby-lang.org/issues/7797#change-35996

Author: rosenfeld (Rodrigo Rosenfeld Rosas)
Status: Open
Priority: Normal
Assignee: matz (Yukihiro Matsumoto)
Category: core
Target version: Next Major


Since #7792 has been rejected (although I don't really understand the reason except people being afraid of changing I guess) I'd like to propose an alternative solution to most of the problems caused by the differences between symbols and strings.

From my previous experience, most of the time I'm accessing a hash, I'd prefer that it behaved like HashWithIndifferentAccess (HWIA from now) from active_support gem.

Transforming all possible hashes in some object to HWIA is not only boring to do code but also time consuming.

Instead, I propose that {}.class == Hash, with Hash being implemented as HWIA and the current Hash implementation renamed to StrictHash.

That way, this should work:

a = {a: 1, 'b' => 2}
a[:a] == a['a'] && a['b'] == a[:b]

I don't really see any real use case where people really want to have a hash like this:

h = {a: 1, 'a' => 2}

This would only confuse people.

It also avoids confusion when parsing/unparsing from popular serialization formats, like JSON:

currently:

h = {a: 1}
j = JSON.unparse h
h2 = JSON.parse j
h[:a] != h2[:a]

With the new proposition (I'm assuming JSON should use Hash instead of StrictHash when parsing) h[:a] == h2[:a].

This is just a small example but most real-world usage for hashes would benefit from regular hashes behaving like HWIA.


-- 
http://bugs.ruby-lang.org/