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-Status: No, score=-2.6 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,UNPARSEABLE_RELAY 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 9E79E1F4B4 for ; Tue, 29 Sep 2020 17:08:49 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 2C332120966; Wed, 30 Sep 2020 02:08:11 +0900 (JST) Received: from xtrwkhkc.outbound-mail.sendgrid.net (xtrwkhkc.outbound-mail.sendgrid.net [167.89.16.28]) by neon.ruby-lang.org (Postfix) with ESMTPS id CA389120936 for ; Wed, 30 Sep 2020 02:08:08 +0900 (JST) Received: by filterdrecv-p3iad2-df8579867-9cwgk with SMTP id filterdrecv-p3iad2-df8579867-9cwgk-18-5F736A14-E3 2020-09-29 17:08:36.827726052 +0000 UTC m=+673805.119162667 Received: from herokuapp.com (unknown) by geopod-ismtpd-3-7 (SG) with ESMTP id ENynkWc-QMqRlK-1gjk6rQ for ; Tue, 29 Sep 2020 17:08:36.751 +0000 (UTC) Date: Tue, 29 Sep 2020 17:08:36 +0000 (UTC) From: shevegen@gmail.com Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 76061 X-Redmine-Project: ruby-master X-Redmine-Issue-Tracker: Feature X-Redmine-Issue-Id: 17171 X-Redmine-Issue-Author: marcandre 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?6lbdtOg4RDRLuxD00eQtQKgoNAsge5d4xND7cbMQd0yKaQcapRQhZGFsYSZOXG?= =?us-ascii?Q?6dtcS0+dSx0kHL5BlFzQUdAYwESVmHlGZaloI6O?= =?us-ascii?Q?3lZo5ZpQJ5+tO8zkUtwC=2Fesn03WYvtlhHM1eKGO?= =?us-ascii?Q?4xvVm0RhrndRAETisr6E6VKe+08Djj3s5eWLEfs?= =?us-ascii?Q?=2FnCNU=2FKhq49yMNmd900dr3JvVnAxEju2hWEuX5v?= =?us-ascii?Q?justc20eyNLmvFK4M=3D?= To: ruby-core@ruby-lang.org X-ML-Name: ruby-core X-Mail-Count: 100220 Subject: [ruby-core:100220] [Ruby master Feature#17171] Why is the visibility of constants not affected by `private`? 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 #17171 has been updated by shevegen (Robert A. Heiler). I am not quite as active on the bug-tracker as I used to be in the past, but I will comment on this particular issue since the reasoning given makes sense to me. I will not comment on the backwards-incompatibility issue much at all, but let me state that I feel that the backwards-incompatibility is a separate consideration to make. For example, matz could approve of the idea here (if he agrees on it), but decide to delay changes here to some later stage for some ruby 3.x release in the future, or perhaps 4.0. There are quite a few changes that may come past ruby 3.0 anyway, but I feel that for this particular discussion here, it may be better to separate between the issue itself ("make constants private too"), and any incompatibility issue as a secondary consideration IF the proposed change would receive the "go-ahead" signal. Otherwise we may have problems discussing and changing anything, because the fear of incompatibility prevents any change, which would be bad too, in particular past ruby 3.0. I also think that a deprecation period is perfectly fine, so I disagree with byroot; I also don't think it has the same impact as keyword arguments or frozen strings. Do note that I do not disagree with his comment that this may lead to broken code - yep, this is most likely true. I just think that a deprecation time is perfectly viable IF matz decides to approve this proposal. For example, when frozen strings were introduced, just about none of my ruby code would have worked. Nowadays, all my ruby code works 100% with frozen strings (or, say, 99.5%; I have not ported ALL my old ruby code, but I can easily do so step by step, so it really is a non-issue to me). And here, a deprecation time did help. So I disagree with byroot on that particular note - I think deprecation would be perfectly fine. Just give people some time to adjust their code, it will slowly happen. Make sure to communicate this too, because not everyone reads the bugtracker. :) So, next, I will focus only on the suggestion itself, without consideration for backwards incompatibility. ------------------------------------------------------------------------------- Let me "preface" this by saying that I don't often use "private". I also don't use .public_send(). To me .send() is more logical, and "private" is also not quite as logical - but this may depend on the OOP style that one uses. For example, Java users may perhaps prefer a stricter distinction whereas smalltalk users may prefer more unrestricted objects; I can understand that. At any rate, while I am not really the target audience for the proposed change, and while I am not a big fan of "private" in general (by the way, nobody mentions "protected" ... hahaha :D), what marcandre writes still makes a LOT of sense to me. Why is that so? Well, simple. Consider a .rb file where the ruby developer writes "private" in the middle of that .rb file, just as shown by marcandre in the example above (we can ignore the CONSTANT for the moment). Ok, we can expect that all methods past that point are now "private" too, thus more restricted than by default. That is the natural way to use private, yes? IF if you come from THAT point of view, where the simple use of "private" switches the other methods that follow towards the state of "more restrictions" than the default "public" does, then actually what marcandre writes, makes a LOT of sense to me as well. - If the methods are private, why not the constants too? Makes sense what is written there really. You can of course say that constants and methods are not directly linked, yes; perhaps "private" implies more "private_method" only. I am not so sure, but let's just assume this for the moment, that a ruby user could specifically want _ONLY_ the methods to be private, and _NOT_ the constants. And we can have longer APIs, such as "private_method" and "private_constant" perhaps - I feel this is a bit separate to the issue at hand, though. Aka, what "private" really means in this context. So, the key question then is: - What does "private" entail, and, following this - How much control should ruby users have over ruby code in this regard? The second part in particular feels 100% like a language design choice, so for matz to decide. Even then, though, I think it makes a lot of sense to me here what marcandre wrote. I think this will apply by far to most ruby code as well out there, if they use "private" in this way - at the least as an intention. The intention seems to clearly be to put all methods into a "more restricted" state. (Yes, some older ruby code may have problems, as byroot pointed out, but that is a separate consideration to make, in my opinion.) IF the ruby user uses "private" in the way shown by marcandre, to me it also means that the user is saying something like this: "Ruby, please, I would like to have all the code that follows there to be more restricted, to avoid funky outside use of this code". And to me, if this instruction given to ruby is true, then it would also make a lot of sense to apply this restriction to constants just as well, if you come from that point of view or a similar point of view. I can not say whether that was the same point of view marcandre used, but I come to the same conclusion in the end, so +1 from my side on that proposed change. To me it seems "logical" (even if it may not be logical per se, but I think marcandre is right; most people may probably assume that a restriction should occur, IF private is used in that manner. And that is coming from someone who rarely uses private; I just feel it really makes sense, since it will capture the intention of most ruby users IMO.) So, TL;DR, +1 from me. ------------------------------------------------------------------------------- ---------------------------------------- Feature #17171: Why is the visibility of constants not affected by `private`? https://bugs.ruby-lang.org/issues/17171#change-87809 * Author: marcandre (Marc-Andre Lafortune) * Status: Open * Priority: Normal ---------------------------------------- ```ruby class Foo def call_me # ... end private SOME_DATA = %i[...].freeze # is public, why not private? def calc_stuff # is private, ok. # ... end end ```ruby It's probably a naive question, but why shouldn't `SOME_DATA`'s visibility be private? When writing gems, more often than not the constants that I write are not meant for public consumption. I find it redundant (and tiresome) to explicitly write `private_constant :SOME_DATA`. -- https://bugs.ruby-lang.org/