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.9 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,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 8470F1F454 for ; Fri, 8 Nov 2019 20:54:16 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 2920F120AAA; Sat, 9 Nov 2019 05:54:06 +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 397B0120A72 for ; Sat, 9 Nov 2019 05:54:03 +0900 (JST) Received: by filter0100p3las1.sendgrid.net with SMTP id filter0100p3las1-5139-5DC5D5EE-59 2019-11-08 20:54:06.84664918 +0000 UTC m=+83255.243122376 Received: from herokuapp.com (unknown [18.209.44.199]) by ismtpd0126p1mdw1.sendgrid.net (SG) with ESMTP id jwJjUEV7TYywtKABZ-SXTw for ; Fri, 08 Nov 2019 20:54:06.650 +0000 (UTC) Date: Fri, 08 Nov 2019 20:54:06 +0000 (UTC) From: dylan.smith@shopify.com Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 71389 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 16336 X-Redmine-Issue-Author: dylants X-Redmine-Sender: dylants 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?dye2b5k+s5R=2FP40aJKRU6ni9RfYjcVEz=2FzZF8dlJcydfyhakfSrMSQA4A5K9F8?= =?us-ascii?Q?d6byZPogTawlnKvEpKkPWN0hrvHuMOvIwYuTrjS?= =?us-ascii?Q?wZXxxB1ciDyqFLA4uyoQThbvDhpVtvmhCi+jHL+?= =?us-ascii?Q?KXfx2Xj1YJyXpFpyakWEUsDB3r6d+vXl0ECb1Hv?= =?us-ascii?Q?pdwSvz2VlgUliIAaeF7PDPAu8B1JQ=2FVTSaQ=3D=3D?= To: ruby-core@ruby-lang.org X-ML-Name: ruby-core X-Mail-Count: 95764 Subject: [ruby-core:95764] [Ruby master Feature#16336] Allow private constants to be accessed with absolute references 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 #16336 has been reported by dylants (Dylan Thacker-Smith). ---------------------------------------- Feature #16336: Allow private constants to be accessed with absolute references https://bugs.ruby-lang.org/issues/16336 * Author: dylants (Dylan Thacker-Smith) * Status: Open * Priority: Normal * Assignee: * Target version: ---------------------------------------- The purpose of constant privacy is to keep a constant from being accessed from outside the namespace. As such, it can be surprising at first when something like the following doesn't work ```ruby # in foo/a.rb module Foo class A end private_constant :A end # in foo/b.rb module Foo class B Foo::A # => NameError: private constant Foo::A referenced end end ``` Once the unexpected behaviour is understood, it can be worked around by using a relative constant reference (changing `Foo::A` to `A` in the example). However, the developer isn't just writing the code for the machine to understand, they are also writing it so it will be clear to other developers, where using the parent namespace in the constant reference may be appropriate for the readability of the code. Instead, I think a reference to a private constant should be allowed through its parent namespace (as is the case with absolute constant references) if the parent namespace is in `Module.nesting` and the constant reference isn't made through a dynamic value (e.g. `foo = Foo; foo::A` wouldn't be allowed in the above example). This will have the additional advantage that it will be easier to make a constant private, since these private constant references through their parent namespace won't have to be updated to remove the parent namespace from the constant reference. I've opened pull request https://github.com/ruby/ruby/pull/2664 with a fix for this issue. -- https://bugs.ruby-lang.org/