From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS4713 221.184.0.0/13 X-Spam-Status: No, score=-3.4 required=3.0 tests=AWL,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI, MIME_HTML_MOSTLY,RCVD_IN_DNSWL_MED,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from neon.ruby-lang.org (neon.ruby-lang.org [221.186.184.75]) by dcvr.yhbt.net (Postfix) with ESMTP id 0A49B20248 for ; Mon, 1 Apr 2019 16:07:44 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 9155C121461; Tue, 2 Apr 2019 01:07:39 +0900 (JST) Received: from mail-vk1-f182.google.com (mail-vk1-f182.google.com [209.85.221.182]) by neon.ruby-lang.org (Postfix) with ESMTPS id 752BF120AC1 for ; Tue, 2 Apr 2019 01:07:31 +0900 (JST) Received: by mail-vk1-f182.google.com with SMTP id 195so2226327vkx.9 for ; Mon, 01 Apr 2019 09:07:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=1ve/dMBnKEnuKDW3iexXHZhcKnQ1kWrp4wWcAiugN8o=; b=a7a+6JYB/V5eR2qnC+EtxiyDkhAS2GFu0sVrODmVMXLrApk/WuJe8YaGhLIehfoGdp oWgQJO/dz5uAabuMp+OL6ualxCWW/uIdNX/yehTTaANbM5VQ9YNdLT2t+DWp9OnKevbI jOJJeeSbZTY1De1woIRAsW6kh0xHwXGkZJKYMlyKve+qXJDsD6XLPuy55CMk27Q5vlVD qgxaQI++IC2Beo2WOciyBDtoIosaaIar8HJp5y/ZwdAW+xfqhYeU1RkjS+FTPlPLeY2w 3nBtWGmIqahyYI7AoQnmug2Ry/YdNnT5cHJGNGZcd/Ymh9ExWhxm9WCbpaK21i1ve3hn q/eA== X-Gm-Message-State: APjAAAU30Qnz0LhiDOgDuWu7zzGPXDtiLZ/j8l7DZKOkWSdN29UTZyip z+u2YbFtA1I672BxJkOItNIqAp8inFXDKS7/Z7eDjA== X-Google-Smtp-Source: APXvYqzpwYS3GRfAahOHbsambVRhkZqJ7wbw63UG6xA5g/tnNc7KmbGShqDqcmGR+BDAbqtUaD1Xg8nBm0d80/7NQ4k= X-Received: by 2002:a1f:10a0:: with SMTP id 32mr4369230vkq.12.1554134851124; Mon, 01 Apr 2019 09:07:31 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Austin Ziegler Date: Mon, 1 Apr 2019 12:07:14 -0400 Message-ID: To: Ruby developers X-ML-Name: ruby-core X-Mail-Count: 92094 Subject: [ruby-core:92094] Re: [Ruby trunk Misc#15723] Reconsider numbered parameters X-BeenThere: ruby-core@ruby-lang.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Ruby developers List-Id: Ruby developers List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1153277959==" Errors-To: ruby-core-bounces@ruby-lang.org Sender: "ruby-core" Content-Transfer-Encoding: 7bit --===============1153277959== Content-Type: multipart/alternative; boundary="000000000000bc125505857a37dd" --000000000000bc125505857a37dd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable In general, I=E2=80=99m OK with this change, but I think that there=E2=80= =99s a possible scoping issue with these automatic variables that I=E2=80=99m not sure that= has been considered: outer.each { puts @1 @1.each { puts @1 } } Elixir doesn=E2=80=99t have this issue because you *can=E2=80=99t* declare = nested declarations this way. But in Ruby, you would no longer have access to the outer `@1`. I=E2=80=99m not sure what other languages similar to Ruby do. -a On Sun, Mar 31, 2019 at 5:35 AM wrote: > Issue #15723 has been updated by zverok (Victor Shepelev). > > > (my small branch in this burning fire) > > For me the biggest problem with the new feature is not the particular > syntax, but the simple fact that the feature (as far as I can understand) > is "orphan", just kinda "nice (or not-that-nice, depends on personal > preference) thing to have, why not". > > I'd argue that intuitive inclining to "don't repeat variable name in > simple blocks" is a good and Rubyish thing, but the solution with "hack" > (just throwing some syntax on top) leads us nowhere. `@1`/`@2` doesn't > provide new concepts that can be reused in different contexts; it doesn't > give a push to rethink how to structure code; it doesn't like any other > feature and absolutely unrelated to them (or rather confusingly similar t= o > instance variables -- without trying to conceptualize it, like, for > example, saying "OK, let's say `Proc` instance has internal instance > variables named `@`, and ..."). > > Counter-example of "good feature" in 2.7 (even if some dislike the syntax= ) > is `&obj.:method` thing. It targets the same audience ("I want my blocks > DRYer"), and probably even will lose the competition if both will be > released in 2.7 (because `map { File.read(@1) }` is kinda "easier to > explain" than `map(&File.:read)`). But "method reference" feature leads t= o: > * more functional and well-thought code -- designing library and > application methods that are easier to use in such chains, without "5 > optional arguments"; > * movement towards first-class method objects, that are acceptable and > usual to people to see stored in variables and collections, passed to oth= er > methods and so on; > * keep people thinking on good design for real powerful currying (not the > one we have now, which is too verbose and obscure to use), to, maybe, mak= e > their peace with something like > > ```ruby > HTTP.get(url).body.then(&JSON.:parse.(symbolyze_names: true)) > ``` > > So, it is about overall shifting of idiomatics towards "functional" way, > which could be argued about (whether it is good or bad thing), but at lea= st > it is **conscious shift of idiomatics**. > > Numbered parameters is "just semantic hack", it doesn't change anything > conceptually, just challenges the parsers and makes syntax incompatible > with previous versions in a hard way (which, again, is not necessary a ba= d > thing, but definitely a bad thing for _just convenience_ feature). > > ---------------------------------------- > Misc #15723: Reconsider numbered parameters > https://bugs.ruby-lang.org/issues/15723#change-77387 > > * Author: sos4nt (Stefan Sch=C3=BC=C3=9Fler) > * 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**, somethi= ng > 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 =E2=80=93 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 =3D Hash.new { |hash, key| hash[key] =3D "Go Fish: #{key}" } > > # vs > > h =3D Hash.new { @1[@2] =3D "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 Rub= y > Style Guide]( > https://github.com/rubocop-hq/ruby-style-guide#no-perl-regexp-last-matche= rs > )) > > > 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 =E2=80=93 it gives context. With more th= an one > parameter, naming is crucial. And yes, naming is hard. But avoiding prope= r > 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: > > --=20 Austin Ziegler =E2=80=A2 halostatue@gmail.com =E2=80=A2 austin@halostatue.c= a http://www.halostatue.ca/ =E2=80=A2 http://twitter.com/halostatue --000000000000bc125505857a37dd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In general, I=E2=80=99m OK with this change, but I think t= hat there=E2=80=99s a possible scoping issue with these automatic variables= that I=E2=80=99m not sure that has been considered:

outer.each {
=C2=A0 puts=C2=A0@1
=C2=A0 @1.each {
=C2=A0 =C2=A0 puts=C2=A0@1
=C2=A0 }
}

Elixir doesn=E2=80=99t have = this issue because you *can=E2=80=99t* declare nested declarations this way= . But in Ruby, you would no longer have access to the outer `@1`.

I=E2=80=99m not sure what other languages similar to Ruby d= o.

-a

On Sun, Mar 31, 2019 at 5:35 AM <zverok.offline@gmail.com> w= rote:
Issue #15723 has been updated by zverok (Vi= ctor Shepelev).


(my small branch in this burning fire)

For me the biggest problem with the new feature is not the particular synta= x, but the simple fact that the feature (as far as I can understand) is &qu= ot;orphan", just kinda "nice (or not-that-nice, depends on person= al preference) thing to have, why not".

I'd argue that intuitive inclining to "don't repeat variable n= ame in simple blocks" is a good and Rubyish thing, but the solution wi= th "hack" (just throwing some syntax on top) leads us nowhere. `@= 1`/`@2` doesn't provide new concepts that can be reused in different co= ntexts; it doesn't give a push to rethink how to structure code; it doe= sn't like any other feature and absolutely unrelated to them (or rather= confusingly similar to instance variables -- without trying to conceptuali= ze it, like, for example, saying "OK, let's say `Proc` instance ha= s internal instance variables named `@<num>`, and ...").

Counter-example of "good feature" in 2.7 (even if some dislike th= e syntax) is `&obj.:method` thing. It targets the same audience ("= I want my blocks DRYer"), and probably even will lose the competition = if both will be released in 2.7 (because `map { File.read(@1) }` is kinda &= quot;easier to explain" than `map(&File.:read)`). But "method= reference" feature leads to:
* more functional and well-thought code -- designing library and applicatio= n methods that are easier to use in such chains, without "5 optional a= rguments";
* movement towards first-class method objects, that are acceptable and usua= l to people to see stored in variables and collections, passed to other met= hods and so on;
* keep people thinking on good design for real powerful currying (not the o= ne we have now, which is too verbose and obscure to use), to, maybe, make t= heir peace with something like

=C2=A0 ```ruby
=C2=A0 HTTP.get(url).body.then(&JSON.:parse.(symbolyze_names: true)) =C2=A0 ```

So, it is about overall shifting of idiomatics towards "functional&quo= t; way, which could be argued about (whether it is good or bad thing), but = at least it is **conscious shift of idiomatics**.

Numbered parameters is "just semantic hack", it doesn't chang= e anything conceptually, just challenges the parsers and makes syntax incom= patible with previous versions in a hard way (which, again, is not necessar= y a bad thing, but definitely a bad thing for _just convenience_ feature).<= br>
----------------------------------------
Misc #15723: Reconsider numbered parameters
https://bugs.ruby-lang.org/issues/15723#change-7= 7387

* Author: sos4nt (Stefan Sch=C3=BC=C3=9Fler)
* Status: Feedback
* Priority: Normal
* Assignee:
----------------------------------------
I just learned that *numbered parameters* have been merged into Ruby 2.7.0d= ev.

For readers not familiar with this feature: it allows you to reference bloc= k 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 progr= amming** 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 =E2=80=93 I c= an *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 usefu= l when dealing with a single argument. You can't have multiple `it`-s o= r `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 =3D Hash.new { |hash, key| hash[key] =3D "Go Fish: #{key}" }
# vs

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

> Don't use the cryptic Perl-legacy variables denoting last regexp g= roup 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 =E2=80=93 it gives context. With more = than one parameter, naming is crucial. And yes, naming is hard. But avoidin= g 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 o= r ditch the feature entirely.



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

Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=3Dunsubscribe= >
<http://lists.ruby-lang.org/cgi-bin/m= ailman/options/ruby-core>


--
Austin Ziegler =E2=80=A2 halostatue@gmail.com =E2=80=A2 austin@halostatue.ca
http://www.ha= lostatue.ca/ =E2=80=A2 http://twitter.com/halostatue
--000000000000bc125505857a37dd-- --===============1153277959== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============1153277959==--