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

Issue #17472 has been updated by duerst (Martin D=FCrst).


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_ke=
ys or stringify or what have you). I don't know if this suggestion is the r=
ight solution for the problem but I was hoping we could at least agree ther=
e'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. T=
hat 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 th=
e default.


> A small thought: I think the original sin in Ruby was making name in {nam=
e: '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. Havin=
g `:name` be a symbol, but `name:` be a string would be highly confusing. A=
nd keys (i.e. member names) in data structures usually are identifiers rath=
er 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 inst=
ead. And if a developer really needed symbol keys (which us Rails devs actu=
ally never do), he could have perhaps written {:name =3D> 'joe'} or whateve=
r. 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 defaul=
t hash keys would have been strings and that's that (correct me if I'm wron=
g but that's how it is in most programming languages; I don't see js or pyt=
hon devs insisting on symbol hash keys).

Javascript doesn't have symbols in the first place, so I don't see how JS d=
evs could insist on symbol hash keys anyway. I also haven't found symbols i=
n 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 na=
tural to treat JSON keys as symbols or as strings, you would have to look a=
t 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, n=
ot only in syntax but also in semantics. If you work with Javascript and Ru=
by, 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 awar=
e 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.rubyonrail=
s.org/classes/ActiveSupport/HashWithIndifferentAccess.html), which is widel=
y used in Rails to handle Request, Session, ActionView's form construction,=
 ActiveRecord's DB communication, and so on. It receives String or Symbol a=
nd normalize them to fetch the value. But it is implemented with Ruby. If w=
e provide C implementation of that, Rails will gain the performance improve=
ment.

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



-- =

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

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