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=-2.8 required=3.0 tests=AWL,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_PASS shortcircuit=no autolearn=no 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 6976C1F4C0 for ; Tue, 15 Oct 2019 17:21:08 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id E3F94120A1B; Wed, 16 Oct 2019 02:20:58 +0900 (JST) Received: from o1678948x4.outbound-mail.sendgrid.net (o1678948x4.outbound-mail.sendgrid.net [167.89.48.4]) by neon.ruby-lang.org (Postfix) with ESMTPS id 828A5120A1A for ; Wed, 16 Oct 2019 02:20:56 +0900 (JST) Received: by filter0035p3iad2.sendgrid.net with SMTP id filter0035p3iad2-757-5DA5FFD5-51 2019-10-15 17:20:21.396160081 +0000 UTC m=+346233.905745447 Received: from herokuapp.com (unknown [52.91.31.13]) by ismtpd0033p1iad2.sendgrid.net (SG) with ESMTP id w9Z2aJIbR1qqkOPalRigfQ for ; Tue, 15 Oct 2019 17:20:21.369 +0000 (UTC) Date: Tue, 15 Oct 2019 17:20:21 +0000 (UTC) From: shevegen@gmail.com Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 70930 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 16253 X-Redmine-Issue-Author: Dan0042 X-Redmine-Sender: shevegen X-Mailer: Redmine X-Redmine-Host: bugs.ruby-lang.org X-Redmine-Site: Ruby Issue Tracking System X-Auto-Response-Suppress: All Auto-Submitted: auto-generated X-SG-EID: =?us-ascii?Q?6lbdtOg4RDRLuxD00eQtQKgoNAsge5d4xND7cbMQd0yyoMXz8TAwndlsvOiCP=2F?= =?us-ascii?Q?pTczhA6KmItBjJodXg5h88Ar2L773kE8fuelbW=2F?= =?us-ascii?Q?z+=2Fdy6V8mP8wc5z21q3U9LDhrgkLUyhvfYdSOAz?= =?us-ascii?Q?EiWOD6HnJhSUm4t6Bix883ZBuMiC=2Fz5V3vZA=2FkF?= =?us-ascii?Q?Uq+y4pvfcP2GwnOIpJDDY2YthQKlmHRj0sQ=3D=3D?= To: ruby-core@ruby-lang.org X-ML-Name: ruby-core X-Mail-Count: 95342 Subject: [ruby-core:95342] [Ruby master Feature#16253] Shorthand "forward everything" syntax 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ruby-core-bounces@ruby-lang.org Sender: "ruby-core" Issue #16253 has been updated by shevegen (Robert A. Heiler). Hmm. I have not decided whether I like the proposal or not; I guess I am mostly neutral, but with a slight tendency towards not being in favour of it. But leaving this aside, I think there are perhaps a few points of note. 1) Part of this proposal reminds me of delegate/delegation, e. g. delegating calls from one object to another - a bit like the Forwardable module may do. So a small issuer may be for other ruby users to understand the difference(s), towards the proposal here, and the forwardable module. 2) I think the core idea behind the proposal is primarily to save some keys, which on the one hand may be nice; on the other hand .... hmmm. To me personally, I do not understand why * would or could be used/retrofitted into meaning to "just pass all arguments". You also wrote that you are fine with other syntax; I believe that it may be better to see whether we could come up with another syntax altogether that still is short, could be used here, without adding a new meaning to *. Benoit mentioned that there were other tickets for use of (...); I am not sure if there are other tickets for this specifically, but I recall having read that in other tickets, perhaps even proposed by matz (I don't remember, sorry). I think using (...) would be a bit better than using/retrofitting *, even though * uses fewer characters. I am not a huge fan of (...) either though, but I do not dispute that it can be, in principle, useful. (Actually I just noticed that the link Benoit used pointed to your own suggestion. :D) Personally I think getting the syntax "right" would be best. I am not sure how useful it would be, or how often it could be used; that might also have to be kept in mind. The recent python 3.8.0 release, for example, there was quite some discussion here and there about how useful or often used some of these features are. IMO whenever possible, the more people who CAN use a feature, and who also WILL use a feature, the better - so getting the syntax "right" here would be important. I don't have a good proposal myself though. I'll use a verbose dummy-example: def foo(*bar) @some_other_object.foo(yield_arguments) That's way too verbose, but I guess it may illustrate the goal of wanting to "yield the arguments onto that method". Actually we may have that already? Or perhaps not ... we have __method__ ... perhaps we may need __arguments__ too and then some syntactic sugar for it. It also reminds me a bit of "yield" and &proc - but anyway, IMO syntax matters. .foo(...) is a bit better than .foo(*) IMO, but not perfect. It may be difficult to get "great" results with very short syntax alone, withouting losing meaning. > And we'd even be future-proof if an eventual FOURTH kind of > parameter is introduced!!!! I don't think this is a good argument ;) because IF this were a problem, one could always suggest a proposal to see a change. You can even find old joke-proposals such as: def foo def bar def ble enddd Or something like that. :P (Although I do have to admit that using several "end" can be a bit tedious; I just think that was a joke proposal since ... who in his sane mind wants to just spam the character "d", to mean end-of-scope, as several "end" would mean. Mandatory indent is also not that great either; I hate that I can't just copy/paste into the interactive python interpreter. IRB's behaviour is so much nicer and more convenient here.) > If rubyists must be told they have to change their forwarding code in 2.7 > (due to keyword arguments), the pill might be easier to swallow if the change > is a reduction rather than an increase in verbosity. Well. I think matz said that this may be the only (or perhaps just one of the very few) changes between 2.x and 3.0, possibly the biggest one. I don't know the status about frozen Strings, but there are always those who like changes, and those who don't. Giving people time to prepare to switch is, IMO, always a good thing; it helps reduce problems in the long run. I don't think people are THAT opposed to change. But to come back to your comment - I don't think that the changes in regards to keyword arguments, should be connected to any syntax proposal in regards to delegation, for several reason. One is that I think they are not really that much connected; but also because the change in regards to keywords came, at the least partially, because it was confusing to many people. Matz even made jokes about it during some presentations. I personally use oldschool hash options usually, barely any keyword arguments, so I am not affected really either way. Perhaps it would also be interesting to see what Jeremy thinks about syntax shortcuts/proposal in this regard, not solely confined to (*) or (...) but just in general. ---------------------------------------- Feature #16253: Shorthand "forward everything" syntax https://bugs.ruby-lang.org/issues/16253#change-82052 * Author: Dan0042 (Daniel DeLorme) * Status: Open * Priority: Normal * Assignee: * Target version: ---------------------------------------- What about using this: ```ruby def foo(*) @bar.foo(*) ``` to mean this: ```ruby def foo(*a, **o, &b) @bar.foo(*a, **o, &b) ``` I used `def foo(*)` because that's currently valid ruby code, but I'm fine with any syntax. It's like the no-parentheses `super` shorthand, but for any method. It makes it easier to write correct forwarding code. If rubyists must be told they have to change their forwarding code in 2.7 (due to keyword arguments), the pill might be easier to swallow if the change is a reduction rather than an increase in verbosity. And we'd even be future-proof if an eventual FOURTH kind of parameter is introduced!!!! -- https://bugs.ruby-lang.org/