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


I personally like the change. I think it is good for quick debugging.

Stefan picked only one example, though:

    Hash.new { @1[@2] = "Go Fish: #{@2}" }

Who says that people have to write code like the above? Also, who claims
that this "must" be in production code? I don't quite understand Stefan
here.

Consider the following code for example:

    big_array_data_structure_with_lots_of_entries.each {|name_of_person, age_of_person, hash_where_this_person_may_live, hash_storing_the_favourite_cats_of_this_person|
      pp @3

      if @4.has_key? 'tom'
        pp 'yup he has a cat named tom'
      end

    }

None of the above would really make it into production code, but I do
happen to have code that is vaguely similar to the above. Actually I
put all the lines with "pp" and the rest on the very left hand side,
so that when I finish writing the code, I can easily remove all the
pp statements. The alternative to the above would be to have to 
use the longer parameters names, and the code does not magically
become "better" just because I use the longer name. And I would
remove the @1 @2 etc... lateron anyway, so I am not sure why Stefan
thinks that everyone will end up including this in their code? Is
there some mysterious cat sitting on the shoulder of people forcing
them to let that code remain? I can not remove the pp @3 at a later
time anymore?

I am not stating that this is very pretty, yes, I agree here, it won't
win beauty contests. But we can say the same about $1 $2 $3 etc... but
also other features/syntax changes, so I don't think this is a very
good argument against the feature in general.

> So please reconsider numbered parameters.

Please don't. :D (I am actually serious though, I like that change.)

In general I think you simply have to find a style that is comfortable for
you in ruby, and then use what you prefer here, and reject what you dislike.
I do that in many other ways too, e. g. not needing @@foo variables, but
others like/use them. But anyway, matz said it is up for feedback, so I 
guess you all should use that opportunity and comment, if you would like
to, EITHER way, and ideally also state WHY you like (or not like) the
change.

PS: Before I forget, though, Stefan referred to the 8 years old suggestion.
This is understandable, but I would like to remind everyone that it is not
solely about that suggestion alone - there have been other comments made
over the years. For example, I first thought that the suggestion would be to
have mandatory names given to the parameters, like:

    object.each {|a, b, c|

And only then to refer to it (e. g. via @1 @2 etc..., but we can also omit
the names. I have no strong preference either way, since I think both variants
have advantages; but I think personally I'll prefer the variant where I give
names, but STILL would like to be able to easily access that with a number.

My main argument is not about beauty, though - it is of "practical use". When
I work with a data structure, it can be much easier for me to remember the
position, rather than the name I gave. Perhaps that may be an argument that
others also have, in the way they write ruby code. As matz once said (and it
is true in general), people are different. And ruby has always been multi-paradigm
(and "more than one way"), even if OOP is in my opinion ruby's core approach.

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

* Author: sos4nt (Stefan Schler)
* 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/

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>