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=-4.1 required=3.0 tests=AWL,BAYES_00, 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 0580C1F4C0 for ; Thu, 24 Oct 2019 02:19:32 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 88E77120B6B; Thu, 24 Oct 2019 11:19:22 +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 094FF120AD0 for ; Thu, 24 Oct 2019 11:19:20 +0900 (JST) Received: by filter0169p3mdw1.sendgrid.net with SMTP id filter0169p3mdw1-4607-5DB10A2A-1D 2019-10-24 02:19:22.348678735 +0000 UTC m=+186122.422695188 Received: from herokuapp.com (unknown [52.90.27.11]) by ismtpd0061p1iad2.sendgrid.net (SG) with ESMTP id A5iJ8odnSq22i9D4jTgyYg for ; Thu, 24 Oct 2019 02:19:22.165 +0000 (UTC) Date: Thu, 24 Oct 2019 02:19:22 +0000 (UTC) From: shyouhei@ruby-lang.org Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 71116 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 16276 X-Redmine-Issue-Author: adh1003 X-Redmine-Sender: shyouhei 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?jcfQDMoo=2FMGCmP3uu1SeyLQUxUPXq5PjHpHz3xSFn15Z9E2AX+yJmu8ySuQWjx?= =?us-ascii?Q?11ZXdhZW=2F5W09YzsD7k1paLhqpyuOMLEuW6yKe+?= =?us-ascii?Q?b7zYgdCdYKOkamzESeRJokKkW5xhsRj9eFQeOqr?= =?us-ascii?Q?I50FlC+YECv0RuRbUzuQwA31ibAlUVKQpsNTFKp?= =?us-ascii?Q?QWrNn1awCahgyzcwHbjH9htZUmNdO3YPEpA=3D=3D?= To: ruby-core@ruby-lang.org X-ML-Name: ruby-core X-Mail-Count: 95524 Subject: [ruby-core:95524] [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 shyouhei (Shyouhei Urabe). - C++: There are `private`, but no `private {}` - Java: There are `private`, but no `private {}` - Scala: There are `private`, but no `private {}` - Kotlin: There are `private`, but no `private {}` - Rsut: Everything are private by default, there is `pub` instead. But the= re is no `pub {}` Correct me if I'm wrong. But it seems the idea of "private with a block" i= sn't seen anywhere. ---------------------------------------- Feature #16276: For consideration: "private do...end" / "protected do...end" https://bugs.ruby-lang.org/issues/16276#change-82299 * 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: