Feature #11105: ES6-like hash literals

• Status: Rejected
• Assignee: -
• Target version: -

[shugo (Shugo Maeda)]

Why not support ECMAScript6-like hash literals?

For example,

{x, y}

is equivalent to:

{x: x, y: y}

For convenience, the prefix of global, instance, and class variables should be removed from the key name as follows:

a = 1
B = 2
$c = 3
@d = 4
@@e = 5
p({a, B, $c, @d, @@e, f: 6})
#=> {:a=>1, :B=>2, :c=>3, :d=>4, :e=>5, :f=>6}

[hsbt (Hiroshi SHIBATA)]

Hi Martin.

I fixed this issue. it is caused by latest version of redmine.
Please try to report again.

Thanks.

On Wed, Apr 29, 2015 at 2:02 PM, "Martin J. Dürst"
[e-mail] wrote:

I tried to reply to Shugo on bugs.ruby-lang.org. However, I got the
following validation message:

"% Done is not included in the list"

I do not know why I would have to indicate "% Done" on a feature that we
only just started discussing. I also don't know where/how I would be
indicating this (I could easily set the percentage to 0 if I knew where to
do that).

Regards, Martin.

--
SHIBATA Hiroshi [e-mail]
http://www.hsbt.org/

[shugo (Shugo Maeda)]

2015-04-29 10:19 GMT+09:00 Matthew Kerwin [e-mail]:

Shugo Maeda wrote:

Why not support ECMAScript6-like hash literals?

Does it make code easier to read, or just easier to write? Personally I find
it a bit confusing/obfuscated.

The proposed syntax contributes to readability because it reduces redundancy and
tells us that a key has the same name as the corresponding variable.

For example, it is obvious that only name has a different name from
the corresponding variable in the following code:

h = {
  name: username,
  password,
  e_mail
}

[bruka (besnik ruka)]

It does look easier to read but feels like it would be harder to write and
debug.

What if you're typing in a hurry, or doing a lot of copy/paste and somehow
you accidentally omit a key? Currently the interpreter would raise a syntax
error immediately, but with this you would get cryptic logic bugs where the
size of the hash is correct, but the key you want is missing.

Also this pretty much means you can't have an expression as the value i.e.

h = {
  name.upcase,
  email
}

Another issue might be that this basically ties your hash to the naming of
your variables:

def sanitize_name(name, email)
  name = name.upcase
  return { name, email }
end

Which looks fine, but if later on i decide to go back and rename my local
variable, I'd have to go find everywhere i've used that hash and make sure
the key is changed properly. Not sure I want that kind of coupling.

[rosenfeld (Rodrigo Rosenfeld Rosas)]

I use that a lot with CoffeeScript and would love to be able to do the same with Ruby. +1

[mame (Yusuke Endoh)]

-1.

{x, y} is a conventional notation of a mathematical set.
When I read it, I expect it to be equivalent to { x => true, y => true }.

--
Yusuke Endoh [e-mail]

[matz (Yukihiro Matsumoto)]

Question:

What if we have variables with same name and different prefixes? e.g.

a = 1
@a = 2
$a = 3

Matz.

[abracu (Alfredo Bravo Cuero)]

Hola matz

Alfredo Bravo Cuero (@abracu (Alfredo Bravo Cuero))
Open Source culture advocate and Ruby on Rails Developer
| Skype: [e-mail] | Cel [phone]

Enviado desde mi iPad

[shugo (Shugo Maeda)]

Yukihiro Matsumoto wrote:

What if we have variables with same name and different prefixes? e.g.

a = 1
@a = 2
$a = 3

The last one is used with warnings:

lexington:ruby$ cat x.rb
a = 1
@a = 2
$a = 3
p({a, @a, $a})
lexington:ruby$ ./ruby x.rb
x.rb:4: warning: duplicated key at line 4 ignored: :a
x.rb:4: warning: duplicated key at line 4 ignored: :a
{:a=>3}

[shugo (Shugo Maeda)]

Yusuke Endoh wrote:

{x, y} is a conventional notation of a mathematical set.
When I read it, I expect it to be equivalent to { x => true, y => true }.

{x, y} looks like a set of variable bindings, so it's reasonable that each key is a variable name and each value is its value.

[agarie (Carlos Agarie)]

As Yusuke Endoh said, I'd expect this notation to create a Set, not a Hash...

---

Carlos Agarie
[phone] | @carlos_agarie

[rosenfeld (Rodrigo Rosenfeld Rosas)]

Yukihiro Matsumoto wrote:

Question:

What if we have variables with same name and different prefixes? e.g.

a = 1
@a = 2
$a = 3

CoffeeScript would compile to this:

@a=1; a=2; {@a, a} => {a: this.a, a: a}

If the same happens in Ruby, this is what I get in IRB:

> {a: 1, a: 2}
(irb):2: warning: duplicated key at line 2 ignored: :a
=> {:a=>2}

Sounds good to me.

[nobu (Nobuyoshi Nakada)]

Shugo Maeda wrote:

lexington:ruby$ cat x.rb
a = 1
@a = 2
$a = 3
p({a, @a, $a})
lexington:ruby$ ./ruby x.rb
x.rb:4: warning: duplicated key at line 4 ignored: :a
x.rb:4: warning: duplicated key at line 4 ignored: :a
{:a=>3}

Why they make the same symbol?
a, @a and $a are irrelevant, separate variables.
I'd expect {:a=>1, :@a=>2, :$a=>3} without any warnings.

[shugo (Shugo Maeda)]

Nobuyoshi Nakada wrote:

lexington:ruby$ ./ruby x.rb
x.rb:4: warning: duplicated key at line 4 ignored: :a
x.rb:4: warning: duplicated key at line 4 ignored: :a
{:a=>3}

Why they make the same symbol?
a, @a and $a are irrelevant, separate variables.
I'd expect {:a=>1, :@a=>2, :$a=>3} without any warnings.

Because I don't come up with any use case of such ugly key names.
I believe code like {a, @A (A A)} should not be used in real world applications.

[matz (Yukihiro Matsumoto)]

• Status changed from Open to Rejected

I am not positive about this syntax mostly because it appears to be set syntax, or old style hash in 1.8.
Once ES6 syntax become more popular, there will be chance for this change in the future.

Matz.

[znz (Kazuhiro NISHIYAMA)]

• Related to Feature #13137: Hash Shorthand added

[znz (Kazuhiro NISHIYAMA)]

• Related to Feature #11104: ES6-like hash literals added

[tleish (Tony Fenleish)]

+1

While it might be odd or new for some, using this in ES6 has been very nice. I am often wishing this was supported in Ruby. The cognitive load is so much nicer and less redundant.

I wish it could be reconsidered.

[knu (Akinori MUSHA)]

This syntax is now widely known and popular in the JavaScript/ES world. It is frequently used in everyday code and we've grown used to it.

[kernigh (George Koehler)]

This ES6 syntax for hash literals looks strange to me. I have never seen it before today, but I have not written JavaScript for a few years, and I am not using Ruby for web development.

Two things puzzle me:

1. What is the key in {@a}? I want :@a as the key, others want :a. I don't expect Ruby to change a into @a. For example, object.instance_variable_get :a raises NameError, but object.instance_variable_get :@a works.
2. Should {print} call the method print if there's no local variable? That's what {print: print} would do.

[nobu (Nobuyoshi Nakada)]

It makes many conflicts with the current syntax.
I don't think it is easy to resolve.

[shugo (Shugo Maeda)]

• Related to Feature #14579: Hash value omission added

[nobu (Nobuyoshi Nakada)]

• Has duplicate Feature #15236: add support for hash shorthand added

[znz (Kazuhiro NISHIYAMA)]

• Related to Feature #16095: 2 Features: remove (simplify) 'new' keyword and Property Shorthand added