[burlesona]

> Calling a private method with a literal self as the receiver is now allowed.

Oof. Call me old fashioned, but I liked the consistency of not being able to call private methods with an explicit receiver. Oh well!

The rest of this looks great, thanks Ruby team!

[atmosx]

Funny thing: I always bring up how Ruby has private methods while Python doesn't, when toying around with colleagues about languages, etc. well there goes that I guess.

Sidenote: I can't think of a use case where this is a good idea.

[cheald]

You've been able to use `send` to pierce the protected/private restriction forever, so this doesn't particularly change the nature of Ruby's method visibility rules. Now you can just use `self.foo` and it's the same as `self.send :foo`.

    class Foo
      def test
        priv             # works
        self.send(:priv) # works
        self.priv        # doesn't work under ruby 2.6-
        Foo.new.priv     # doesn't work
      end

      private

      def priv
        puts "ran private"
      end
    end

You shouldn't typically need to be using `self` at all, except when it's clarifying or disambiguating, so you shouldn't generally run into that issue. On occasion, though, you add a `self.` prefix to a method call and can break code that was otherwise working, because you've subjected your code to a scope protection that it wasn't subject to before.

[atmosx]

> You've been able to use `send` to pierce the protected/private restriction forever, so this doesn't particularly change the nature of Ruby's method visibility rules.

I wasn't aware, thanks for pointing that out.

[Lio]

Previously this was a good reason for preferring public_send over send where possible.