Project

General

Profile

Actions

Feature #11105

closed

ES6-like hash literals

Added by shugo (Shugo Maeda) over 9 years ago. Updated about 7 years ago.

Status:
Rejected
Assignee:
-
Target version:
-
[ruby-core:69012]

Description

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}

Files


Related issues 5 (0 open5 closed)

Related to Ruby master - Feature #13137: Hash ShorthandRejectedActions
Related to Ruby master - Feature #11104: ES6-like hash literalsRejected04/29/2015Actions
Related to Ruby master - Feature #14579: Hash value omissionClosedmatz (Yukihiro Matsumoto)Actions
Related to Ruby master - Feature #16095: 2 Features: remove (simplify) 'new' keyword and Property ShorthandRejectedActions
Has duplicate Ruby master - Feature #15236: add support for hash shorthandRejectedActions

Updated by hsbt (Hiroshi SHIBATA) over 9 years ago

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"
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
http://www.hsbt.org/

Updated by shugo (Shugo Maeda) over 9 years ago

2015-04-29 10:19 GMT+09:00 Matthew Kerwin :

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
}

Updated by bruka (besnik ruka) over 9 years ago

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.

Updated by rosenfeld (Rodrigo Rosenfeld Rosas) over 9 years ago

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

Updated by mame (Yusuke Endoh) over 9 years ago

-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

Updated by matz (Yukihiro Matsumoto) over 9 years ago

Question:

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

a = 1
@a = 2
$a = 3

Matz.

Updated by abracu (Alfredo Bravo Cuero) over 9 years ago

Hola matz

Alfredo Bravo Cuero (@abracu (Alfredo Bravo Cuero))
Open Source culture advocate and Ruby on Rails Developer
| Skype: | Cel +573192837240

Enviado desde mi iPad

Updated by shugo (Shugo Maeda) over 9 years ago

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}

Updated by shugo (Shugo Maeda) over 9 years ago

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.

Updated by agarie (Carlos Agarie) over 9 years ago

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


Carlos Agarie
+55 11 97320-3878 | @carlos_agarie

Updated by rosenfeld (Rodrigo Rosenfeld Rosas) over 9 years ago

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.

Updated by nobu (Nobuyoshi Nakada) over 9 years ago

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.

Updated by shugo (Shugo Maeda) over 9 years ago

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.

Updated by matz (Yukihiro Matsumoto) over 9 years ago

  • 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.

Actions #15

Updated by znz (Kazuhiro NISHIYAMA) almost 8 years ago

Actions #16

Updated by znz (Kazuhiro NISHIYAMA) almost 8 years ago

Updated by tleish (Tony Fenleish) over 7 years ago

+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.

Updated by knu (Akinori MUSHA) about 7 years ago

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.

Updated by kernigh (George Koehler) about 7 years ago

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.

Updated by nobu (Nobuyoshi Nakada) about 7 years ago

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

Actions #21

Updated by shugo (Shugo Maeda) over 6 years ago

Actions #22

Updated by nobu (Nobuyoshi Nakada) about 6 years ago

Actions #23

Updated by znz (Kazuhiro NISHIYAMA) about 5 years ago

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

Also available in: Atom PDF

Like0
Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0