[ruby-core:92906] [Ruby trunk Misc#15723] Reconsider numbered parameters

[shevegen@gmail.com]

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


> TBH, I wish the multi numbered parameters feature would not make it in
> preview1. But now that it did, it's becoming urgent to fix it.

This is based on the assumption that there has to be a "fix" at all in the first place
to begin with; and if so, what the assumed "fix" would then be.

Naturally, if you come from the point of view that nothing is broken to begin with, then
nothing has to be fixed in this regard (or any similar situation). So I actually think
that nothing is broken here - and hence, nothing has to be fixed as a consequence.

This is an opinion, of course, just as well as any other point of view coming from another
opinion (e. g. the opinions to "fix" or not to "fix", or to not make any change at all).

The word "fix" also does not appear to be a very good fit, since it appears to imply that
something is broken to begin with; perhaps a more neutral word may be to ask whether a
particular change is necessary or not. The whole feature is experimental right now.

> I don't want Ruby to become Perl in terms of readability. Naming variables
> helps understanding the code, especially when it's more than one argument.

So ... let me understand this statement here:

If @2 @3 @4 is used, then the ruby code that someone writes automatically becomes ...
perl - yet, if the same ruby user uses e. g. $2 $3 $4, then the ruby code does not
become perl (in regards to readability)? And .: and & and @@ any other syntax is ...
not perl?

Hmmmmm.

To me this does not seem to be a very compelling/logical statement.

I don't quite see how the ruby code that I write automatically becomes perl code merely
due to me using @2 @3 and so forth. Or why $1 $2 would not, either. I use $1 $2 a lot; I
don't use most of the other perl-inspired variables such as $< or whatever they were,
largely because it is  difficult for me to remember them. I used to write quite some perl
in the past and I can happily say that there is just no comparison between ruby and perl.
The ruby code that I write has always been MUCH better than perl in regards to 
readability (to me). Note that I tend to write fairly simple ruby code in general; I try
to not want to confuse myself when I write code.

I do not see any problem with code such as this:

    @big_monster_array.each {|name, student_id, country, etc...

      # add lots of code here
      #
      # lots of lines of code 
      #
      # forget the specific name of the variables there
      #
      # now I scroll upwards ... or have some IDE that helps
      # me, but I still have to think. I have to think less
      # when I can just do:

pp @2 # just debug to see what was going on; the wrong indent
      # level is deliberate, to make it easier to see what can be removed lateron
      # and pseudo code can be written on it, then tested,
      # and then removed/replaced again once things work

    }

Why would you assume that this code is never used; or that @2 must be used in
production and remain there?

I don't see the logical connection here. To me it seems more as if people dislike a
particular feature, and then base their arguments on that dislike primarily - "sloppy
programming" or "urgent fix" of "perl code in ruby". This is understandable (human
nature) but I don't see why other use cases should be rejected primarily because of
emotion and personal likes/dislikes.

Also, as for random polls - I did not even know of that poll to begin with.

Does it seem fair to make statements about any particular like/dislike of any
feature with random polls? If so, can we have cat polls?

I am not completely against polls as such, mind you, as they can still provide some
useful information provided that they are useful and representative, but the design
of a language should not be based on random polls-first and most definitely NOT with
any targeted intent, e. g. based on likes or dislikes per se to reinforce some 
particular opinion. And IF there are polls, then these should be systematic and
inclusive for all proposed features/changes - but I am against that.

As Shyouhei Urabe once wrote in a comment/blog - language designers need to be able to
have the freedom to operate and consider trade-offs and changes; and I agree with this.

Many of the ideas and suggestions proposed in, say, the last ~5 years or so in particular,
did not come by matz himself directly, but came by other folks making suggestions, reasoning
in support of their own ideas (logically), often coming from different backgrounds, and
having different use cases.

In my opinion, it would be much better if the whole suggestion/discussion could focus
more on objective criteria, in particular (potential) use cases; and then potential
pitfalls.

Right now it seems to be a lot more on "emotion-first", and to then reason in favour
of like/dislikes. Which is understandable, but I don't think this is a good way to 
reason in favour or against something per se or primarily. So please, no random
polls that not everyone knew about or had a chance to relate to.

By the way, as far as I understood it, the single argument (for block arguments) is
not exactly the same as being able to programmatically access block parameter/data.
So it can not be used interchangably.

To conclude, and to give another opinion than benoit with his urgent change necessary -
I think it is good that the preview includes an early possibility for ruby users to
use a particular feature (or not use it), and to then give feedback based on that
usage as such (or also, use it, and then think that you may not need/want it too).

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

* Author: sos4nt (Stefan Schüßler)
* Status: Feedback
* Priority: Normal
* Assignee: matz (Yukihiro Matsumoto)
----------------------------------------
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.

---Files--------------------------------
implicit-param.diff (20 KB)


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