From: Austin Ziegler Date: 2019-10-31T23:21:56-04:00 Subject: [ruby-core:95626] Re: [Ruby master Feature#16276] For consideration: "private do...end" / "protected do...end" --===============0187318415== Content-Type: multipart/alternative; boundary="000000000000d718500596407893" --000000000000d718500596407893 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I=E2=80=99m mostly against (and I have a Ruby coding style that @duerst doe= sn=E2=80=99t like). I was using something similar in Elixir, and eventually I decided that I didn=E2=80=99t like it and am in the process of removing it from pro= jects where we have it. -a On Wed, Oct 30, 2019 at 4:04 PM wrote: > Issue #16276 has been updated by jeremyevans0 (Jeremy Evans). > > > adh1003 (Andrew Hodgkinson) wrote: > > There seems to be a general agreement that this proposed extension woul= d > be a good thing > > I'm not seeing general agreement that this would be a good thing to add. > In this ticket: > > @shevegen : mostly neutral, very slight #+1 > @duerst : no recommendation > @shyouhei : no recommendation > @marcandre : neither for nor against > @Eregon : kind of like, but double-edged sword > @jeremyevans0 : not worth adding > > In #7019, it appeared that @shyouhei, @drbrain, @headius, @ko1, and @mame > didn't think it was worth adding. > > Where are you seeing general agreement that this proposed extension would > be a good thing? > > > ---------------------------------------- > Feature #16276: For consideration: "private do...end" / "protected > do...end" > https://bugs.ruby-lang.org/issues/16276#change-82383 > > * Author: adh1003 (Andrew Hodgkinson) > * Status: Open > * Priority: Normal > * Assignee: > * Target version: > ---------------------------------------- > Private or protected declarations in Ruby classes are problematic. The > single, standalone `public`, `private` or `protected` statements cause al= l > following methods - *except* "private" class methods, notably - to have > that protection level. It is not idiomatic in Ruby to indent method > definitions after such declarations, so it becomes at a glance very hard = to > see what a method's protection level is when just diving into a piece of > source code. One 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 this). Forcibly indenting code after > declarations helps, but most Ruby developers find this unfamiliar and mos= t > auto-formatters/linters will reset it or, at best, complain. Further, the > difficulty in defining private *class* methods or constants tells us that > perhaps there's more we should do here - but of course, we want to mainta= in > backwards compatibility. > > On the face of it, I can't see much in the way of allowing the `public`, > `private` or `protected` declarations to - *optionally* - support a > block-like 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_applie= s > puts "I'm also traditional" > end > > end > ``` > > My suggestion here confines all `public do...end`, `protected do...end` o= r > `private do...end` protections strictly to the confines of the block alon= e. > Outside the block - both before and after - traditional Ruby protection > semantics apply, allowing one to add new block-based protection-enclosed > method declarations inside any existing code base without fear of > accidentally changing the protection level of any methods defined below t= he > new block. As 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=C3=AFve - for examp= le, > arising unanswered questions include: > > * Is the use of a block-like syntax making unwarranted assumptions about > what the Ruby compiler can do during its various parsing phases? > * Does the use of a block-like syntax imply we should support things like > Procs too? (I *think* probably not - I see this as just syntax sugar to > provide a new feature reusing a familiar idiom but without diving down an= y > other rabbit holes, at least not in the first implementation) > > I've no idea how one would go about implementing this inside Ruby Core, a= s > 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 > could be sketched out, then I might be able to have a go at implementatio= n > myself and submit a PR - assuming anyone is keen on the idea in the first > place `:-)` > > > > > -- > https://bugs.ruby-lang.org/ > > Unsubscribe: > > --=20 Austin Ziegler =E2=80=A2 halostatue@gmail.com =E2=80=A2 austin@halostatue.c= a http://www.halostatue.ca/ =E2=80=A2 http://twitter.com/halostatue --000000000000d718500596407893 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I=E2=80=99m mostly against (and I have a Ruby coding style= that=C2=A0@duerst doesn=E2=80=99t like). I was using something similar in = Elixir, and eventually I decided that I didn=E2=80=99t like it and am in th= e process of removing it from projects where we have it.

-a

On Wed, Oct 30, 2019 at 4:04 PM <merch-redmine@jeremyevans.net> wrote:
Issue #16276 has been updated by jeremyevans0 (Jeremy Evans)= .


adh1003 (Andrew Hodgkinson) wrote:
> There seems to be a general agreement that this proposed extension wou= ld be a good thing

I'm not seeing general agreement that this would be a good thing to add= .=C2=A0 In this ticket:

@shevegen : mostly neutral, very slight #+1
@duerst : no recommendation
@shyouhei : no recommendation
@marcandre : neither for nor against
@Eregon : kind of like, but double-edged sword
@jeremyevans0 : not worth adding

In #7019, it appeared that @shyouhei, @drbrain, @headius, @ko1, and @mame d= idn't think it was worth adding.

Where are you seeing general agreement that this proposed extension would b= e a good thing?


----------------------------------------
Feature #16276: For consideration: "private do...end" / "pro= tected do...end"
https://bugs.ruby-lang.org/issues/16276#change-8= 2383

* 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 ha= ve that protection level. It is not idiomatic in Ruby to indent method defi= nitions after such declarations, so it becomes at a glance very hard to see= what a method's protection level is when just diving into a piece of s= ource code. One must carefully scroll *up* the code searching for a relevan= t declaration (easily missed, when everything's at the same indentation= level) or have an IDE sufficiently advanced to give you that information a= utomatically (and none of the lightweight editors I prefer personally have = yet to support this). Forcibly indenting code after declarations helps, but= most Ruby developers find this unfamiliar and most auto-formatters/linters= will reset it or, at best, complain. Further, the difficulty in defining p= rivate *class* methods or constants tells us that perhaps there's more = we should do here - but of course, we want to maintain backwards compatibil= ity.

On the face of it, I can't see much in the way of allowing the `public`= , `private` or `protected` declarations to - *optionally* - support a block= -like syntax.

```
class Foo

=C2=A0 # ...there may be prior old-school public/private/protected declarat= ions...

=C2=A0 def method_at_whatever_traditional_ruby_protection_level_applies
=C2=A0 =C2=A0 puts "I'm traditional"
=C2=A0 end

=C2=A0 private do
=C2=A0 =C2=A0 def some_private_instance_method
=C2=A0 =C2=A0 =C2=A0 puts "I'm private"
=C2=A0 =C2=A0 end

=C2=A0 =C2=A0 def self.some_private_class_method
=C2=A0 =C2=A0 =C2=A0 puts "I'm also private - principle of least s= urprise"
=C2=A0 =C2=A0 end

=C2=A0 =C2=A0 NO_NEED_FOR_PRIVATE_CONSTANT_DECLARATIONS_EITHER =3D "pr= ivate"
=C2=A0 end

=C2=A0 def another_method_at_whatever_traditional_ruby_protection_level_app= lies
=C2=A0 =C2=A0 puts "I'm also traditional"
=C2=A0 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=C3=AFve - for exa= mple, arising 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 f= eature, great! Alternatively, if a rough idea of how it *might* be implemen= ted could be sketched out, then I might be able to have a go at implementat= ion myself and submit a PR - assuming anyone is keen on the idea in the fir= st place `:-)`




--
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=3Dunsubscribe= >
<http://lists.ruby-lang.org/cgi-bin/m= ailman/options/ruby-core>


--
Austin Ziegler =E2=80=A2 halostatue@gmail.com =E2=80=A2 austin@halostatue.ca
http://www.ha= lostatue.ca/ =E2=80=A2 http://twitter.com/halostatue
--000000000000d718500596407893-- --===============0187318415== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Unsubscribe: --===============0187318415==--