Dear language designer(s) and parser wizards,
can we allow hash literals like {1:2, 3:4, 5:6} (for numbers, or even
better, for general keys)? I think that would be the best replacement
for the old list notation. my guess is that people are using the
following types of keys most (sorted by importance):
- Symbols
- Strings
- Special objects (not containers)
- Fixnums
- constants (eg. classes)
- (who uses containers for keys? yugh!)
I'd love Ruby 1.9 to allow the following:
Symbols: { foo: 23, bar: 42 } (already supported in 1.9)
Strings: { 'foo': 23, 'bar': 42 } (used a lot)
Numbers: { 1:1, 3:9, 2:4 } (shortcut, looks like a multiset)
Objects: typically given as variables. Tricky, because if foo is a local
variable, { foo: 3 } would be ambiguous. So we need parentheses:
foo = Foo.new 313
{ default: 0, (foo): 'Hash me!', (Math::PI): 3.14 }
That would of course allow basically everything:
{ (/default/): 0, (()): (()), ({a:0}):0, ([1,2,3])::a,
(ENV.keys.map(&:upcase)): :":", (foo): 7, (Foo): 7, foo: 7 }
but the classic => notation also allows this:
{ /default/ => 0, () => (()), {:a=>0} => 0, [1,2,3] => :a,
ENV.keys.map(&:upcase) => :":", foo => 7, Foo: 7, :foo => 7 }
Another solution would be just to handle keys that look like identifiers
(local variables, methods and constants) special and interpret them as
Symbols, and make the colon an alternative to => for everything else.
you only have to use parentheses around local variables and constants then:
{ /default/: 0, (): (()), {a:0}:0, [1,2,3]::a,
ENV.keys.map(&:upcase): :":", (foo): 7, (Foo): 7, foo: 7 }
(code golfers, cheer!)
Since the current implementation even allows => and : to be mixed in a
literal, it seems already to be smart enough to parse everything up to
the colon:
SyntaxError: (irb):10: parse error, expecting `tASSOC'
{ {a: 3}: 3}
^
So, are there design or technical reasons not to allow general hask keys
in the new colon notation?
(or am I asking an old question that can be answered with a link?)
[murphy]