-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rage Against the Params #1279
Rage Against the Params #1279
Conversation
This rather blurs the line between the fundamental difference between symbols and strings, huh? The whole point of symbols is that you could replace every symbol, say |
@b264 String hash keys are automatically frozen, and have been for quite some time:
So in practice, string and symbol hash keys are functionally equivalent, and I believe they perform just as well as each other. This particular "problem" that Sinatra tries to solve with IndifferentHash (and Rails solves with HashWithIndifferentAccess) is due to Rack always using string keys to store the parsed query parameter string. Most Rubyists prefer to use symbol keys in their code, so this pattern of casting symbols to strings has developed over time. In a perfect world, Rack would (optionally?) use symbol keys for this data structure, but I guess that would break too many things. I'd say it's fairly limited to a handful of use cases—mostly this one—so I don't see it as endemic, but that's just my perception. Most Rubyists I've observed seem to grok symbols and prefer to use them wherever possible. |
it's fixed on 2.0.0.rc2 but not working at all on 2.0.0.rc6. |
hash problems accessing hash in post request through params as described |
That's an old question, and it's about Rails, not Sinatra. What are you
trying to do and what's not working?
|
Have you ever been frustrated that
params.has_key?(:sym)
works, but notparams.key?(:sym)
?Have you ever tried to use
params.dig(..)
with symbol keys? How about#fetch
or#values_at
?Does this snippet of code make your blood pressure spike?
How about the fact that query parameters are mapped to string keys, but Sinatra's internal
captures
parameter is mapped to a symbol key? So even if you commit to using all string keys for params, you may still run into issues.Our IndifferentHash implementation is simultaneously too indifferent and not indifferent enough. One might say it is indifferently indifferent! I propose we make it fully-indifferent, and remove as much "astonishment" as humanly possible. Here is a PR that does just that.