ruby-core@ruby-lang.org archive (unofficial mirror)
 help / color / mirror / Atom feed
From: shevegen@gmail.com
To: ruby-core@ruby-lang.org
Subject: [ruby-core:89475] [Ruby trunk Feature#15236] add support for hash shorthand
Date: Fri, 19 Oct 2018 14:13:24 +0000 (UTC)	[thread overview]
Message-ID: <redmine.journal-74516.20181019141321.aebd1fe3742c831c@ruby-lang.org> (raw)
In-Reply-To: redmine.issue-15236.20181019103301@ruby-lang.org

Issue #15236 has been updated by shevegen (Robert A. Heiler).


Hmm. It's hard for me to say whether I am in favour of this suggestion or
whether I am not.

I think this link may help a bit in regards to JavaScript, even though
JavaScript is not Ruby; neither is the syntax:

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Object_initializer

Old JavaScript variant:

    var o = {};
    var o = {a: 'foo', b: 42, c: {}};

versus New JavaScript variant:

    var a = 'foo', b = 42, c = {};
    var o = {a, b, c};

I understand the second part being more convenient and more concise. I am not
really sure whether it makes sense for ruby to adopt this, though.

The part where "omission means something more", is sometimes confusing.

I myself got used to be able to omit {} in a method definition, such as
your example:

    m(a, b, c: c)

which I think would be this:

    m(a, b, { c: c })

I also use the somewhat new Hash syntax in ruby a lot, like:

    foo: :bar

versus the old variant (but still the "real" variant)

    :foo => :bar

I am not entirely sure about the new omission-meaning-infinity
in ranges ( 1 .. ) either, or { a } meaning { a: a } like in the
proposal here, where a is a variable that must exist already,
if { a } is to work. This also reminds me a bit about the 
shortcut suggestion for initializing instance variables within
the method-argument, rather than the body of the method at 
hand (usually "def initialize").

I don't really have a definite pro or con view but I think it
should be thought through for some time either way. While experienced
ruby developers have it easy learning new syntax parts, newcomers may
have to gradually learn more and  more syntax parts, which may not be
ideal for them, even if the new syntax may be shorter. Or where the
syntax allows us to do more with {}, rather than with Hash.new - that
should also be considered to evaluate all trade-offs and
advantages/disadvantages.

If you would like to, you could add your suggestion to any upcoming
developer meeting where you could get some opinions from the ruby core
team and of course matz (which would be at
https://bugs.ruby-lang.org/issues/15229 for the next one in November
2018; or perhaps for a later one in January 2019 since I assume 
most energy of the team may go into the upcoming x-mas release of
ruby :) ).

----------------------------------------
Feature #15236: add support for hash shorthand
https://bugs.ruby-lang.org/issues/15236#change-74516

* Author: ignatiusreza (Ignatius Reza Lesmana)
* Status: Open
* Priority: Normal
* Assignee: 
* Target version: 
----------------------------------------
PR in github: https://github.com/ruby/ruby/pull/1990

inspired by javascript support for object literal shorthand notation `{ a }`, which will be expanded into `{ a: a }`..

to avoid ambiguity, this shorthand is only supported when hash is defined with `{ }` notation.. in other situation where the brackets is optional, e.g. function call, we still need to write it in full (`m(a : a)` instead of `m(a)`, or `m(a, b, c: c)` instead of `m(a, b, c)`..



-- 
https://bugs.ruby-lang.org/

  parent reply	other threads:[~2018-10-19 14:13 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <redmine.issue-15236.20181019103301@ruby-lang.org>
2018-10-19 10:33 ` [ruby-core:89468] [Ruby trunk Feature#15236] add support for hash shorthand lyoneil.de.sire
2018-10-19 14:13 ` shevegen [this message]
2018-10-19 14:13 ` [ruby-core:89476] " shevegen
2018-10-19 14:16 ` [ruby-core:89477] " shevegen
2018-10-19 16:23 ` [ruby-core:89478] " edchick
2018-10-20  2:23 ` [ruby-core:89488] " matz
2018-10-22  2:07 ` [ruby-core:89503] " lyoneil.de.sire
2018-10-22  8:54 ` [ruby-core:89507] " janfri26
2018-10-30  0:47 ` [ruby-core:89623] " lyoneil.de.sire
2018-11-02 20:29 ` [ruby-core:89682] " blake.h.l.west
2018-11-02 20:47 ` [ruby-core:89683] " manga.osyo
2018-11-02 20:55 ` [ruby-core:89684] " manga.osyo
2018-11-06  1:21 ` [ruby-core:89716] " lyoneil.de.sire
2019-04-29 17:56 ` [ruby-core:92481] " tleish
2019-06-09  3:11 ` [ruby-core:93030] " lyoneil.de.sire
2019-06-09  4:22 ` [ruby-core:93032] " lyoneil.de.sire
2019-07-29  8:01 ` [ruby-core:93983] [Ruby master " ko1
2019-08-11 15:12 ` [ruby-core:94276] " FreeKMan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.ruby-lang.org/en/community/mailing-lists/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=redmine.journal-74516.20181019141321.aebd1fe3742c831c@ruby-lang.org \
    --to=ruby-core@ruby-lang.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).