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:92106] [Ruby trunk Misc#15723] Reconsider numbered parameters
Date: Tue, 02 Apr 2019 10:22:01 +0000 (UTC)	[thread overview]
Message-ID: <redmine.journal-77433.20190402102201.61b38745722114fe@ruby-lang.org> (raw)
In-Reply-To: redmine.issue-15723.20190322131122@ruby-lang.org

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


I was about to comment on what ted wrote, but it would have become too long,
so here is a significantly shorter variant to just focus on a few points:

- I think "itself" is very similar to "it". Kotlin makes use of "itself", so
it is understandable that some folks may also like to see "itself" in ruby.

In my opinion, though, translating from another language into ruby is not always
trivial, e. g. see elixir's pipe operator. It is, however had, somewhat
interesting to note that languages inspire other languages (or people who use
either language).

- To the name "itself" versus "it" alone. Personally I would prefer "it", if we
were to have only these two choices available. The primary reason is that it is
shorter to type "it" than "itself". For similar reasons "then" is better than
"yield_self" (and I am not even using or needing yield_self either; this is just
a comment).

- If the argument is that the "scope is too limited", well - not every change has
to be of epic proportions either. Omitting require 'pp' is an example of a small
but (to me) very nice change. It is also a bit curious to see that a scope would
be too limited, but to then see another suggestion made. ;)

I think it is perfectly fine to reason in favour of no change too, by the way.
Mame wrote so before. You still have to include the situation that this also
means that you may not get new functionality - see prior changes, such as the
safe navigation operator or the addition of .: or, in the case here, being able
to access block parameters differently ON TOP OF the already existing variant.

It's always a trade-off and you can argue either way, a simpler language with
less syntax (yes), but also fewer features. See also @@foo variables - while
I myself do not use @@ anymore, others use them and have no problem with them,
or have code bases that include them. And without @@ well - you would not
have that feature (which can be good or bad depending on your use case too,
but it is also a lot to the personal opinion, or the "style" that you use
when writing ruby code).

- I am also not entirely sure why some folks reason in favour of things being
mutually exclusive here. Let's ignore for the moment the possibility of no change
at all (and, would that make people happier? Probably not those who would like
any given change suggested in, say, the last three years. But let's just 
ignore the no-change situation for the moment).

Why would it be completely impossible to, for example, add BOTH @1 @2 AND "it"
or "itself" or anything else?

I am not saying that this should be done, either. I am just not entirely sure 
why some reason that it must be mutually exclusive. Why would it not be possible
to offer both? Purely from a theoretical point of view to consider alone.

- Syntax is important, but it is also about features and functionality, which
should not be forgotten. And not everything can be done without change to 
syntax alone.

Take the Io language:

    https://iolanguage.org/about.html
    https://iolanguage.org/tutorial.html

Syntax-wise it is simpler than ruby, possibly. But it also is restricted in
what it can offer, due to that constraint. And less flexible. It's not 
that it is necessarily not elegant, but ruby's syntax is in my opinion much
better. Smalltalk has a, in my opinion, somewhat similar problem syntax
wise.

- yield_with is different as to what Stefan wrote about here; at the least
he did not mention that we would have to use yield_with. It's also not quite
the same or covers other potential use cases, in my opinion, such as accessing
nested Arrays/Hashes. Though we could assume that, for example, "it" could
be treated like MatchData (for procs/blocks, such as ProcData or BlockData,
just to illustrate names), and access via [1] [2] method calls. But even
then it is not the same. In my opinion, long names can be somewhat clumsy,
so it should ideally be short. But this all comes down to personal opinion
really.

----------------------------------------
Misc #15723: Reconsider numbered parameters
https://bugs.ruby-lang.org/issues/15723#change-77433

* Author: sos4nt (Stefan Schüßler)
* Status: Feedback
* Priority: Normal
* Assignee: 
----------------------------------------
I just learned that *numbered parameters* have been merged into Ruby 2.7.0dev.

For readers not familiar with this feature: it allows you to reference block arguments solely by their *index*, e.g.

```ruby
[1, 2, 3].each { |i| puts i }

# can become

[1, 2, 3].each { puts @1 }
```

I have an issue with this new feature: I think **it encourages sloppy programming** and results in **hard to read code**.

---

The [original proposal](https://bugs.ruby-lang.org/issues/4475) was to include a special variable (or keyword) with a **readable name**, something like:

```ruby
[1, 2, 3].each { puts it }

# or

[1, 2, 3].each { puts this }
```

Granted, that looks quite lovely and it actually speaks to me – I can *understand* the code. And it fits Ruby: (quoting the website)

> [Ruby] has an elegant syntax that is natural to read and easy to write.

But the proposed `it` / `this` has limited application. It's only useful when dealing with a single argument. You can't have multiple `it`-s or `this`-es. That's why `@1`, `@2`, `@3` etc. were chosen instead.

However, limiting the usefulness to a single argument isn't bad at at. In fact, a single argument seem to be the limit of what makes sense:
```
h = Hash.new { |hash, key| hash[key] = "Go Fish: #{key}" }

# vs

h = Hash.new { @1[@2] = "Go Fish: #{@2}" }
```
Who wants to read the latter? That looks like an archaic bash program (no offense). We already discourage Perl style `$`-references: (from [The Ruby Style Guide](https://github.com/rubocop-hq/ruby-style-guide#no-perl-regexp-last-matchers))

> Don't use the cryptic Perl-legacy variables denoting last regexp group matches (`$1`, `$2`, etc). Use `Regexp.last_match(n)` instead.

I don't see how our code can benefit from adding `@1` and `@2`.

Naming a parameter isn't useless – it gives context. With more than one parameter, naming is crucial. And yes, naming is hard. But avoiding proper naming by using indices is the wrong way.

So please reconsider numbered parameters.

Use a readable named variable (or keyword) to refer to the first argument or ditch the feature entirely.



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

  parent reply	other threads:[~2019-04-02 10:22 UTC|newest]

Thread overview: 130+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <redmine.issue-15723.20190322131122@ruby-lang.org>
2019-03-22 13:11 ` [ruby-core:91931] [Ruby trunk Misc#15723] Reconsider numbered parameters mail
2019-03-22 13:54 ` [ruby-core:91933] " matz
2019-03-22 14:12 ` [ruby-core:91934] " shevegen
2019-03-22 14:18 ` [ruby-core:91935] " mame
2019-03-22 15:38 ` [ruby-core:91939] " alanwucanada
2019-03-22 16:06 ` [ruby-core:91941] " sawadatsuyoshi
2019-03-22 19:22 ` [ruby-core:91947] " mail
2019-03-24 16:19 ` [ruby-core:91964] " pascal.betz
2019-03-25  1:33 ` [ruby-core:91969] " shyouhei
2019-03-25  4:47 ` [ruby-core:91972] " sawadatsuyoshi
2019-03-25  5:53 ` [ruby-core:91973] " maediprichard
2019-03-25  6:22 ` [ruby-core:91974] " merch-redmine
2019-03-25  7:47 ` [ruby-core:91975] " sawadatsuyoshi
2019-03-25 12:12 ` [ruby-core:91976] " pascal.betz
2019-03-25 12:37 ` [ruby-core:91978] " matz
2019-03-25 16:48 ` [ruby-core:91979] " bozhidar
2019-03-25 17:43 ` [ruby-core:91980] " maediprichard
2019-03-25 18:19 ` [ruby-core:91981] " merch-redmine
2019-03-25 18:59 ` [ruby-core:91982] " maediprichard
2019-03-25 19:18 ` [ruby-core:91983] " merch-redmine
2019-03-25 19:38 ` [ruby-core:91984] " maediprichard
2019-03-26  7:57 ` [ruby-core:91991] " bozhidar
2019-03-26 14:48   ` [ruby-core:91996] " Austin Ziegler
2019-03-26  8:16 ` [ruby-core:91992] " fg
2019-03-26  8:52 ` [ruby-core:91993] " duerst
2019-03-26 12:20 ` [ruby-core:91994] " maediprichard
2019-03-26 14:20 ` [ruby-core:91995] " bozhidar
2019-03-26 15:24 ` [ruby-core:91997] " merch-redmine
2019-03-26 17:12 ` [ruby-core:91998] " stefan
2019-03-26 20:35 ` [ruby-core:92002] " shevegen
2019-03-26 22:15 ` [ruby-core:92003] " blackmoore.joan
2019-03-27  0:32 ` [ruby-core:92004] " matthew
2019-03-27  9:18 ` [ruby-core:92006] " beatmadsen
2019-03-27  9:51 ` [ruby-core:92007] " bozhidar
2019-03-27 10:04 ` [ruby-core:92009] " duerst
2019-03-27 10:26 ` [ruby-core:92010] " beatmadsen
2019-03-27 21:27 ` [ruby-core:92019] " eregontp
2019-03-27 21:40 ` [ruby-core:92021] " eregontp
2019-03-28  0:14 ` [ruby-core:92024] " duerst
2019-03-28 12:25 ` [ruby-core:92035] " mame
2019-03-29  8:21 ` [ruby-core:92047] " v.ondruch
2019-03-29  9:33 ` [ruby-core:92048] " shevegen
2019-03-30 11:57 ` [ruby-core:92056] " bozhidar
2019-03-30 17:06 ` [ruby-core:92058] " dunrix29a
2019-03-31  9:35 ` [ruby-core:92063] " zverok.offline
2019-04-01 16:07   ` [ruby-core:92094] " Austin Ziegler
2019-04-01 23:18     ` [ruby-core:92096] " Martin J. Dürst
2019-04-02  1:29 ` [ruby-core:92097] " matthew
2019-04-02  7:57 ` [ruby-core:92104] " drenmi
2019-04-02 10:22 ` shevegen [this message]
2019-04-02 11:00 ` [ruby-core:92107] " sawadatsuyoshi
2019-04-02 11:39 ` [ruby-core:92108] " darkwiiplayer
2019-04-03  6:48 ` [ruby-core:92122] " burlesona
2019-04-03 10:45 ` [ruby-core:92127] " zah
2019-04-03 11:05 ` [ruby-core:92129] " zah
2019-04-03 12:35 ` [ruby-core:92137] " xoru
2019-04-04  5:23 ` [ruby-core:92143] " drewpvogel
2019-04-04  6:09 ` [ruby-core:92145] " psychoslave
2019-04-04  6:34 ` [ruby-core:92146] " merch-redmine
2019-04-04  9:35 ` [ruby-core:92147] " psychoslave
2019-04-04 10:07 ` [ruby-core:92148] " matthew
2019-04-05  1:01 ` [ruby-core:92152] " drewpvogel
2019-04-05  1:53 ` [ruby-core:92153] " merch-redmine
2019-04-05  8:41 ` [ruby-core:92154] " psychoslave
2019-04-05  9:36 ` [ruby-core:92155] " sawadatsuyoshi
2019-04-05 10:18 ` [ruby-core:92156] " psychoslave
2019-04-05 11:05 ` [ruby-core:92157] " duerst
2019-04-05 12:58 ` [ruby-core:92159] " psychoslave
2019-04-06  0:38 ` [ruby-core:92160] " ruby-core
2019-04-06  1:53 ` [ruby-core:92161] " merch-redmine
2019-04-06  3:36 ` [ruby-core:92162] " ruby-core
2019-04-06  7:00 ` [ruby-core:92164] " sawadatsuyoshi
2019-04-07 18:08 ` [ruby-core:92182] " eregontp
2019-04-07 18:25 ` [ruby-core:92183] " eregontp
2019-04-07 18:43 ` [ruby-core:92184] " eregontp
2019-04-08 11:58 ` [ruby-core:92206] " sawadatsuyoshi
2019-04-08 18:15 ` [ruby-core:92210] " eregontp
2019-04-08 19:17 ` [ruby-core:92212] " pascal.betz
2019-04-08 22:08 ` [ruby-core:92214] " ruby-core
2019-04-09  7:39 ` [ruby-core:92218] " sawadatsuyoshi
2019-04-11  9:33 ` [ruby-core:92244] " loic.nageleisen
2019-04-12 19:11 ` [ruby-core:92259] " headius
2019-04-12 19:12 ` [ruby-core:92260] " headius
2019-04-12 20:08 ` [ruby-core:92261] " eregontp
2019-04-12 20:10 ` [ruby-core:92262] " headius
2019-04-12 20:29 ` [ruby-core:92263] " eregontp
2019-04-12 21:11 ` [ruby-core:92264] " merch-redmine
2019-04-12 22:38 ` [ruby-core:92265] " eregontp
2019-04-13  4:44 ` [ruby-core:92268] " dunrix29a
2019-04-13  8:08 ` [ruby-core:92273] " merch-redmine
2019-04-13 10:09 ` [ruby-core:92276] " eregontp
2019-04-13 10:14 ` [ruby-core:92277] " dunrix29a
2019-04-17 12:13 ` [ruby-core:92316] " merch-redmine
2019-04-17 12:31   ` [ruby-core:92317] " Waheed Al-Barghouthi
2019-04-17 12:34 ` [ruby-core:92318] " waheed.barghouthi
2019-04-17 12:59 ` [ruby-core:92319] " merch-redmine
2019-04-17 14:09 ` [ruby-core:92320] " waheed.barghouthi
2019-04-19 10:28 ` [ruby-core:92328] " maediprichard
2019-04-22 23:09 ` [ruby-core:92371] " chocolate
2019-04-24  2:57 ` [ruby-core:92389] " sawadatsuyoshi
2019-04-24  5:49 ` [ruby-core:92392] " merch-redmine
2019-04-25 15:48 ` [ruby-core:92409] " headius
2019-04-26 19:54 ` [ruby-core:92423] " chocolate
2019-04-26 21:12 ` [ruby-core:92426] " eregontp
2019-04-27  3:13 ` [ruby-core:92429] " nobu
2019-04-30 10:34 ` [ruby-core:92490] " sawadatsuyoshi
2019-05-30 22:19 ` [ruby-core:92896] " eregontp
2019-05-30 22:20 ` [ruby-core:92897] " eregontp
2019-05-31  7:00 ` [ruby-core:92905] " duerst
2019-05-31 12:00 ` [ruby-core:92906] " shevegen
2019-05-31 12:16 ` [ruby-core:92907] " eregontp
2019-05-31 12:44 ` [ruby-core:92909] " eregontp
2019-05-31 12:58 ` [ruby-core:92910] " konsolebox
2019-06-02  3:17 ` [ruby-core:92925] " jo9100
2019-06-05 17:37 ` [ruby-core:92984] " sawadatsuyoshi
2019-06-06  7:28 ` [ruby-core:92998] " konsolebox
2019-06-30 11:55 ` [ruby-core:93429] " eregontp
2019-06-30 12:00 ` [ruby-core:93430] " eregontp
2019-07-03 14:21 ` [ruby-core:93513] [Ruby master " ttilberg
2019-07-14 11:20 ` [ruby-core:93756] " michaur
2019-07-24  7:35 ` [ruby-core:93900] " darkwiiplayer
2019-07-24  8:04 ` [ruby-core:93901] " s+ruby
2019-07-27  9:38 ` [ruby-core:93948] " janosch84
2019-07-30 15:34 ` [ruby-core:94056] " shevegen
2019-07-30 18:59 ` [ruby-core:94059] " eregontp
2019-07-30 22:30 ` [ruby-core:94063] " matthew
2019-08-05 15:25 ` [ruby-core:94149] " daniel
2019-08-29  5:19 ` [ruby-core:94644] " matz
2019-09-07 12:18 ` [ruby-core:94829] " eregontp
2019-10-03 19:16 ` [ruby-core:95202] " paddor

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-77433.20190402102201.61b38745722114fe@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).