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=AWL,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 C7ED81F4C0 for ; Thu, 31 Oct 2019 18:08:27 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id D806F120A44; Fri, 1 Nov 2019 03:08:16 +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 2DB21120A3F for ; Fri, 1 Nov 2019 03:08:13 +0900 (JST) Received: by filter0061p3iad2.sendgrid.net with SMTP id filter0061p3iad2-28236-5DBB2310-11C 2019-10-31 18:08:17.01115498 +0000 UTC m=+76471.810367298 Received: from herokuapp.com (unknown [54.210.198.90]) by ismtpd0002p1iad1.sendgrid.net (SG) with ESMTP id QC2BUdNYQj6xo1uhWhjF4A for ; Thu, 31 Oct 2019 18:08:17.003 +0000 (UTC) Date: Thu, 31 Oct 2019 18:08:17 +0000 (UTC) From: merch-redmine@jeremyevans.net Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 71207 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 16276 X-Redmine-Issue-Author: adh1003 X-Redmine-Sender: jeremyevans0 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?RVE3t853K5scBhbmJHUzZTFFeVC=2FZSUmHZ0Dc+26wcEi2CTgsF1oz0wTSSxGGN?= =?us-ascii?Q?BI9E2S6lncMcnqG5SJQqDSwkpg8ifN2UKSPxWLN?= =?us-ascii?Q?NS3pifbXVcWRypIJCROTbJerKKVnhWYB93kUdtN?= =?us-ascii?Q?arFkVt6K+J+c9TyUX+PB4OeDpa+Wr3rd9m96BMe?= =?us-ascii?Q?rnfDJcnk4oIzzzSPCkYKOWCUOk=2FxbqqpilQ=3D=3D?= To: ruby-core@ruby-lang.org X-ML-Name: ruby-core X-Mail-Count: 95613 Subject: [ruby-core:95613] [Ruby master Feature#16276] For consideration: "private do...end" / "protected do...end" 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Errors-To: ruby-core-bounces@ruby-lang.org Sender: "ruby-core" Issue #16276 has been updated by jeremyevans0 (Jeremy Evans). Dan0042 (Daniel DeLorme) wrote: > Ok, but how is this different from the regular syntax? The exact same iss= ue applies to this: > = > ```ruby > class A > end > = > Thread.new do > class A > def pub; end > end > end > = > class A > private > def priv; end > end > ``` Are you sure? You can test this by using queues to synchronize: ```ruby class A end Q1 =3D Queue.new Q2 =3D Queue.new Thread.new do class A Q2.pop def pub; end Q1.push nil end end class A private def priv; end Q2.push nil Q1.pop end A.public_instance_methods(false) # =3D> [:pub] ``` > If there's no problem with the above, there's no reason why the proposed = block form would have any problem either right? In other words the thread/f= iber issue is irrelevant to the current proposal. There is no problem with fibers/threads currently, because the visibility i= s stored in the scope (not in the class itself). You stated `When the priv= ate method toggles the visibility state of the current class/module`, imply= ing this would implemented with a visibility flag on the class/module. You= cannot have visibility stored in the class/module and handle fibers/thread= s properly without making the class-level visibility information fiber/thre= ad-aware. ---------------------------------------- Feature #16276: For consideration: "private do...end" / "protected do...end" https://bugs.ruby-lang.org/issues/16276#change-82404 * Author: adh1003 (Andrew Hodgkinson) * Status: Open * Priority: Normal * Assignee: = * Target version: = ---------------------------------------- Private or protected declarations in Ruby classes are problematic. The sing= le, standalone `public`, `private` or `protected` statements cause all foll= owing methods - *except* "private" class methods, notably - to have that pr= otection level. It is not idiomatic in Ruby to indent method definitions af= ter such declarations, so it becomes at a glance very hard to see what a me= thod's protection level is when just diving into a piece of source code. On= e must carefully scroll *up* the code searching for a relevant declaration = (easily missed, when everything's at the same indentation level) or have an= IDE sufficiently advanced to give you that information automatically (and = none of the lightweight editors I prefer personally have yet to support thi= s). Forcibly indenting code after declarations helps, but most Ruby develop= ers find this unfamiliar and most auto-formatters/linters will reset it or,= at best, complain. Further, the difficulty in defining private *class* met= hods or constants tells us that perhaps there's more we should do here - bu= t of course, we want to maintain backwards compatibility. On the face of it, I can't see much in the way of allowing the `public`, `p= rivate` or `protected` declarations to - *optionally* - support a block-lik= e syntax. ``` class Foo # ...there may be prior old-school public/private/protected declarations.= .. def method_at_whatever_traditional_ruby_protection_level_applies puts "I'm traditional" end private do def some_private_instance_method puts "I'm private" end def self.some_private_class_method puts "I'm also private - principle of least surprise" end NO_NEED_FOR_PRIVATE_CONSTANT_DECLARATIONS_EITHER =3D "private" end def another_method_at_whatever_traditional_ruby_protection_level_applies puts "I'm also traditional" end end ``` My suggestion here confines all `public do...end`, `protected do...end` or = `private do...end` protections strictly to the confines of the block alone.= Outside the block - both before and after - traditional Ruby protection se= mantics apply, allowing one to add new block-based protection-enclosed meth= od declarations inside any existing code base without fear of accidentally = changing the protection level of any methods defined below the new block. A= s noted in the pseudocode above, we can clean up some of the issues around = the special syntax needed for "private constants", too. I see a lot of wins in here but I'm aware I may be na=EFve - for example, a= rising unanswered questions include: * Is the use of a block-like syntax making unwarranted assumptions about wh= at the Ruby compiler can do during its various parsing phases? * Does the use of a block-like syntax imply we should support things like P= rocs too? (I *think* probably not - I see this as just syntax sugar to prov= ide a new feature reusing a familiar idiom but without diving down any othe= r rabbit holes, at least not in the first implementation) I've no idea how one would go about implementing this inside Ruby Core, as = I've never tackled that before. If someone is keen to pick up the feature, = great! Alternatively, if a rough idea of how it *might* be implemented coul= d be sketched out, then I might be able to have a go at implementation myse= lf and submit a PR - assuming anyone is keen on the idea in the first place= `:-)` -- = https://bugs.ruby-lang.org/ Unsubscribe: