Hi all,
I’m wondering where to pitch an idea and implementation of a new warning. I found that new ruby programmers get confused between strings and symbols especially when using them as keys in hashes. I made a small change that warns when there is a value in the hash with a symbol as its key but you are trying to access it with the equivalent string. E.g.
hash = {this: “that”}
puts hash[“this”]
Warning: no value stored for key “this”. Value found for equivalent symbol key :this. Did you mean to use a symbol?
Any pointers for how to propose this would be greatly appreciated. Thanks!
- miguel
You can use an official bug/proposal tracker: https://bugs.ruby-lang.org/
(it is open for anybody).
About your proposal: I like the friendliness, but I am afraid there would
be performance implications, probably.
···
вт, 23 окт. 2018 г. в 15:47, Miguel A Salinas II <mikeys@me.com>:
Hi all,
I’m wondering where to pitch an idea and implementation of a new warning.
I found that new ruby programmers get confused between strings and symbols
especially when using them as keys in hashes. I made a small change that
warns when there is a value in the hash with a symbol as its key but you
are trying to access it with the equivalent string. E.g.
hash = {this: “that”}
puts hash[“this”]
Warning: no value stored for key “this”. Value found for equivalent symbol
key :this. Did you mean to use a symbol?
Any pointers for how to propose this would be greatly appreciated. Thanks!
- miguel
Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>
Also, existing apps may start generating lots of warnings. What if I store
both string and symbols in a hash?
Best
Greg
I would trigger the warning only after a key miss, so the overhead would only happen in case of a completely missing key. So if you had { foo: 'bar', 'foo' => 'baz', 'boo' => 'blarg' } and you asked for test['foo'] and test[:foo], you would get bar and baz, but if you asked for test[:boo], you would get the warning.
Walter
···
On Oct 23, 2018, at 9:18 AM, Greg Navis <contact@gregnavis.com> wrote:
Also, existing apps may start generating lots of warnings. What if I store both string and symbols in a hash?
Best
Greg
Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>
"What if I store both string and symbols in a hash?"
If I were doing that, I would appreciate a warning.
~ Ale Miralles.
https://medium/amiralles
http://amiralles.com.ar
···
On Tue, 23 Oct 2018 at 10:18, Greg Navis <contact@gregnavis.com> wrote:
Also, existing apps may start generating lots of warnings. What if I store
both string and symbols in a hash?
Best
Greg
Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>
I'm not sure I understand why -- *any* object can be a Hash key, not
only strings or symbols.
If I had a use case for requiring keys to be the same type I would
probably either subclass Hash or rely on a linter like RuboCop.
···
On Tue, Oct 23, 2018 at 8:44 AM Ale Miralles <amiralles.net@gmail.com> wrote:
"What if I store both string and symbols in a hash?"
If I were doing that, I would appreciate a warning.
--
Hassan Schroeder ------------------------ hassan.schroeder@gmail.com
twitter: @hassan
Consulting Availability : Silicon Valley or remote
I'm not sure I understand why -- *any* object can be a Hash key, not
only strings or symbols.
True, but those two are *very* commonly confused, and not only by n00bz.
If I had a use case for requiring keys to be the same type I would
probably either subclass Hash or rely on a linter like RuboCop.
Yeah, subclassing Hash to accept only one kind of key sprang to my
mind too, as the most reliable way, and relatively easy. (Or if you
don't need to use the same value both ways, just use a
HashWithIndifferentAccess. Even if it's not a Rails app so that would
be built in, you can import ActiveSupport, or easily rebuild the same
basic functionality.)
But now you've got me wondering what it would take to make Rubocop
spot it. The trouble would be, just like the thermos keeping hot
stuff hot and cold stuff cold, how would it know? Expecting it to
parse enough of the AST to know what types are already in a hash,
doesn't strike me as feasible -- it could even be undecidable. I
suppose we could tag each one with a comment Rubocop understands, but
that seems like overkill and a PITA. Other wild and crazy ideas?
···
On Tue, Oct 23, 2018 at 1:07 PM Hassan Schroeder <hassan.schroeder@gmail.com> wrote:
--
Dave Aronson, Software Development Consultant
The T. Rex of Codosaurus, LLC
(http://www.Codosaur.us)
What can we help you evolve today?
If I had a use case for requiring keys to be the same type I would
probably either subclass Hash or rely on a linter like RuboCop.
I thought that subclassing the basic collection classes like Hash or Array was a bad idea? Because under the hood, their implementation was optimised, and it could lead to unforeseen effects?
Of course, you can always use composition instead of inheritance.
Click here to view Company Information and Confidentiality Notice.<http://www.jameshall.co.uk/index.php/small-print/email-disclaimer>
Please note that we have updated our privacy policy in line with new data protection regulations. Please refer to our website to view the ways in which we handle your data.
I personally wouldn't like to see a warning like that as there are simple
methods of addressing such confusion.