[ruby-core:103066] [Ruby master Feature#17472] HashWithIndifferentAccess like Hash extension

Issue #17472 has been updated by duerst (Martin Dst).


joelb (Joel Blum) wrote in #note-19:
> > Use JSON.parse(data, symbolize_names: true)
> 
> I know that. Yet the fact is these bugs happen again and again (not only to new Ruby devs, would you agree it's quite easy to forget to symbolize_keys or stringify or what have you). I don't know if this suggestion is the right solution for the problem but I was hoping we could at least agree there's a problem for a sizeable segment of Ruby users.

Maybe we should change the default on JSON.parse? That would probably lead to too much backwards compatibility issues.

Maybe we should introduce a new method where symbol keys are the default. That could be done without backwards compatibility issues, just by spreading the word to use the new method.

Another option may be a global setting that projects could use to change the default.


> A small thought: I think the original sin in Ruby was making name in {name: 'joe'} a symbol, e.g have the new "javascript snytax" use symbol keys.

No. Using a symbol is this location is the right thing to do in Ruby. Having `:name` be a symbol, but `name:` be a string would be highly confusing. And keys (i.e. member names) in data structures usually are identifiers rather than data, so in Ruby, symbols are more appropriate.

If you really want an "original sin", it's that Ruby distinguishes between identifiers (symbols) and strings (see also below).


> I think it would have been better if it was a string / frozen string instead. And if a developer really needed symbol keys (which us Rails devs actually never do), he could have perhaps written {:name => 'joe'} or whatever. And yes it means we would have had to access the hash so: ` hsh['name']` and not `hsh[:name]` (I kinda like the latter for saving a character) but we wouldn't have been having this discussion over and over again. By default hash keys would have been strings and that's that (correct me if I'm wrong but that's how it is in most programming languages; I don't see js or python devs insisting on symbol hash keys).

Javascript doesn't have symbols in the first place, so I don't see how JS devs could insist on symbol hash keys anyway. I also haven't found symbols in Python, so I guess the same thing applies there, too. When searching for "Python symbol", the only stuff I get is sympy. To see whether it's more natural to treat JSON keys as symbols or as strings, you would have to look at other languages that distinguish symbols and strings, e.g. Lisp.


> I don't know if anyone would agree with me here, and I know it's too late to do that anyway, but maybe it's worth mentioning.

Different programming languages just handle different things differently, not only in syntax but also in semantics. If you work with Javascript and Ruby, you have to deal with the fact that in conditions, the empty string and 0 are treated differently. There are other issues that you have to be aware of. Unfortunately, no way of getting around this.



----------------------------------------
Feature #17472: HashWithIndifferentAccess like Hash extension
https://bugs.ruby-lang.org/issues/17472#change-91127

* Author: naruse (Yui NARUSE)
* Status: Open
* Priority: Normal
* Target version: 3.1
----------------------------------------
Rails has [ActiveSupport::HashWithIndifferentAccess](https://api.rubyonrails.org/classes/ActiveSupport/HashWithIndifferentAccess.html), which is widely used in Rails to handle Request, Session, ActionView's form construction, ActiveRecord's DB communication, and so on. It receives String or Symbol and normalize them to fetch the value. But it is implemented with Ruby. If we provide C implementation of that, Rails will gain the performance improvement.

summary of previous discussion: https://github.com/rails/rails/pull/40182#issuecomment-687607812



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

Unsubscribe: <mailto:[e-mail]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>