I’ve only glanced quickly at the article, but I think the author’s understanding of private in Ruby is wrong.<p><pre><code> class Parent
attr_accessor :x
private :x
def initialize(x)
self.x = x
# └── (1) allowed
end
def ==(other)
self.x == other.x
# │ └── (2) not allowed
# └── (1) allowed
end
end
</code></pre>
This is not doing what the author thinks it is doing. Or, it is, but I don’t think the authors understand why. `private :x` <i>only marks the x method as private</i>, but `x=` is a different method.<p>They would see different behavior with<p><pre><code> private :x
private :x=
</code></pre>
In general, public, private, and protected do the following. Public methods can be called with <i>any</i> receiver: explicit (x.foo()), self (self.foo()), or implicit (foo()). Protected methods can be invoked on self or with an implicit receiver. Private methods can only be invoked on an implicit receiver. Note that this has <i>nothing to do</i> with the class hierarchy. A private method can be called from a subclass as long as it has an implicit receiver.<p>The difference between protected and private is not really practically useful, so I personally use them to signal different levels of “private-ness”. I use protected methods to implement a class’ “internal API”, which is the core thing the public API is abstracting and exposing. I use private methods for implementing ancillary details that aren’t really core to what the class does but handle some one-off unrelated data manipulation or munging. But that’s just me.<p>I’ll also admit that something may have changed with Ruby’s rules around these keywords around 3.0 that I missed, so if that’s the case I apologize.