ruby-core

I’m mostly against (and I have a Ruby coding style that @duerst doesn’t
like). I was using something similar in Elixir, and eventually I decided
that I didn’t like it and am in the 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 would
> 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 all
> 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 most
> 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 maintain
> 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 = "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
> 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 the
> 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ïve - for example,
> 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 any
> other 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
> could be sketched out, then I might be able to have a go at implementation
> myself and submit a PR - assuming anyone is keen on the idea in the first
> place `:-)`
>
>
>
>
> --
> https://bugs.ruby-lang.org/
>
> Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>
>


-- 
Austin Ziegler • halostatue@gmail.com • austin@halostatue.ca
http://www.halostatue.ca/ • http://twitter.com/halostatue

Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>