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.9 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 3FF641F4BD for ; Sat, 5 Oct 2019 22:40:47 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id CB01612095E; Sun, 6 Oct 2019 07:40:37 +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 F1141120959 for ; Sun, 6 Oct 2019 07:40:35 +0900 (JST) Received: by filter0145p3mdw1.sendgrid.net with SMTP id filter0145p3mdw1-31881-5D991BE6-1B 2019-10-05 22:40:38.35446117 +0000 UTC m=+102676.062967227 Received: from herokuapp.com (unknown [18.234.90.121]) by ismtpd0010p1iad2.sendgrid.net (SG) with ESMTP id B_PxZrCdT_Src_1A_6BZ8g for ; Sat, 05 Oct 2019 22:40:38.395 +0000 (UTC) Date: Sat, 05 Oct 2019 22:40:38 +0000 (UTC) From: shevegen@gmail.com Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 70824 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 16241 X-Redmine-Issue-Author: palkan 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?6lbdtOg4RDRLuxD00eQtQKgoNAsge5d4xND7cbMQd0xXsmd2XYT5sFw2s0CCuP?= =?us-ascii?Q?hKpqAz7=2F9kjPM8hz9PRyTSEPd309tnm4WOLNka6?= =?us-ascii?Q?piJWnBNvXObSD5NZZOiP5i+8fnVrG92SWQyICdH?= =?us-ascii?Q?=2FY9AHZb5SDF=2F0v2bJWPfKzF=2Fb97KM9NkUHwrwgu?= =?us-ascii?Q?cjvCuSJTOrHknML7ZbXfMEHVzBF=2Fnq2t=2F=2Fw=3D=3D?= To: ruby-core@ruby-lang.org X-ML-Name: ruby-core X-Mail-Count: 95237 Subject: [ruby-core:95237] [Ruby master Feature#16241] Shorter syntax for anonymous refinements 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 #16241 has been updated by shevegen (Robert A. Heiler). Hmm. I think there was another suggestion some months ago that also suggested simplifications or "beautification" in regards to refinements. In general I like ideas that try to make the refinement feature more accessible. Syntax has been the major reason why I have not been using refinements in my own code; oddly enough, I 100% agree that it is a good idea to have refinements, but the syntax always felt ... clunky to me. That is mostly my reasoning why I think simplifications would be nice. Matz provided a good syntactic "base". For example, to subclass, we do: class Foo < Bar That's very expressive and short. Refinements on the other hand always felt a bit too verbose to me. That may be a personal choice/preference, granted; on the other hand, looking at suggestions to simplify or beautify it, it does not seem to be a unique opinion as such. :) (I also have to admit that I once assumed for refinements to work differently, until I read up on the original proposal. I think a few other ruby users may have also mis-interpreted how refinements work now and then. I mention this in particular because I believe matz and the core team would like to have clear definitions for any specifications related to refinements.) I am still not necessarily in big favour of using the word "refining"; it also seems not as good as the "Foo < Bar" notation :) - but on the other hand, this is, I think, still an improvement over the even more (!) verbose variant that you gave as an example. By the way, I also completely agree with you here: > Having shorter syntax could lower the barrier of entry for Rubyist > wanting to explore this feature I think simple/expressive syntax can help a LOT. I think the only complaint I have about "refining" is that the word seems a bit strange to me ... I do not have a better name as suggestion, though. By the way, would we then have two words? E. g. "refine" and "refining"? Because this may lead to confusion; may be better to settle just on one either way. (Or perhaps, if that requires modifications and deprecations, to aim for ruby 4.0 with that, but with simplification as the primary goal.) zverok wrote: > As I've written elsewhere in this tracker, the most useful case for > refinements is "in current module, I want some shortcuts for my > code to look cleaner". Yup, I agree. > So, "inplace refinements" is probably the main kind of refinements > the developer could care; while "refinements in a module" I think we have to be careful here to not make refinements more complicated or complex, or add more than one refinements in place. This is, I think, what is good about the proposal here in principle, since the primary (or sole) aim appears to be to lead to a lighter syntax, which I think would be good, even if the semantics remain the same in regards to refinements. If possible, anyone able to come up with other names or syntax could add a comment or two in regards to the word "refining". I personally have not fully made up my mind yet; I am not in favour or disfavour of the word per se. I think the only statement I can make is that it seems to be better than the older/current variant. But perhaps I am overlooking something; may need someone who has used refinements in the past (I can not remember that other issue where someone has suggested a simplification syntax-wise some months ago ...) ---------------------------------------- Feature #16241: Shorter syntax for anonymous refinements https://bugs.ruby-lang.org/issues/16241#change-81910 * Author: palkan (Vladimir Dementyev) * Status: Open * Priority: Normal * Assignee: * Target version: ---------------------------------------- The original discussion is here https://bugs.ruby-lang.org/issues/14344. tl;dr - Refinements are often used in-place with anonymous modules - Having shorter syntax could lower the barrier of entry for Rubyist wanting to explore this feature - Previous syntax suggestions were not accepted. I suggest adding a shorter syntax (technically, API): ```ruby # before using(Module.new do refine Array do def foo;"bar";end end end) # after refining Array do def foo; "bar"; end end ``` The original idea was to use `using_refined` instead of `refining` but after discussing with Matz we decided that it's too verbose, and `refining` seems better. But is it good enough? Any thoughts? -- https://bugs.ruby-lang.org/