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

[Austin Ziegler <halostatue@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 4031 bytes --]

I define globals all the time for short scripts. It’s rare that I define
`$it`, but I have done so in the past.

On Tue, Mar 26, 2019 at 3:57 AM <bozhidar@batsov.com> wrote:

> Issue #15723 has been updated by bozhidar (Bozhidar Batsov).
>
>
> > $it can already be defined, so this is not backwards compatible.
>
> It can, but that's extremely unlikely, so I think the impact to backwards
> compatibility would be negligible. I've almost never seen anyone define
> globals themselves. I don't think it's wise to eliminate some possibilities
> simply because they *might* cause minimal problems.
>
> Btw, using `%1`, `%2`, `%3` is fine, right? How do people feel about that
> one in general. I'm kind of used to it, because that's how Clojure does it,
> but I'm curious if it feels very weird in general.
>
> > If it will be multiple params @1, @2, etc. Can we also have @ aliasing
> @1? I think it's going to be a common use case to just have the one param.
>
> I think that would look extra weird, but in general it's a good idea
> (especially if the special var had some meaningful name).
>
> ----------------------------------------
> Misc #15723: Reconsider numbered parameters
> https://bugs.ruby-lang.org/issues/15723#change-77321
>
> * 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/
>
> Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>
>


-- 
Austin Ziegler • halostatue@gmail.com • austin@halostatue.ca
http://www.halostatue.ca/ • http://twitter.com/halostatue

[-- Attachment #1.2: Type: text/html, Size: 5444 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]