Christopher Dicely wrote in post #996426:
>> Protected means unavailable outside this class, except to
>> subclasses. What definition of "protected" are you using?
>
> In Java, protected means available to:
...
> In C++, protected means available to:
...

And of course, Ruby has it's own definition of "protected" methods. 
IIRC, it means that any explicit receiver must be in the same class or 
subclass as the sender. I've never used it.

Instance variables are only directly accessible (i.e. as "@bar") from 
instance methods of the current object - there is no syntax available to 
access them on a different object (e.g. "foo.@bar"). This makes them 
"private" by ruby's definition of private. To access them on a different 
object, you'd need foo.instance_variable_get(:@bar), which can be called 
from anywhere.

Since Ruby's protection mechanisms can be bypassed, "private" and 
"protected" are really just API hints. If you have to code awkwardly as

   foo.instance_variable_get(:@bar)
or
   foo.send(:bar)

then it's a hint that the author didn't intend you to do this. But there 
may still be good reasons to do it: for example, the IPAddr class 
doesn't provide any way to access the netmask or prefix length without 
either doing this, or monkey-patching/subclassing. It can also be useful 
when testing internals, or when initializing where you don't want to 
expose a setter method:

  class MyStruct
    def self.inherited(subclass)
      subclass.instance_variable_set(:@foo, {})
    end
  end

  class X < MyStruct; end   # class auto-initialized

In that example, you might argue that a protected accessor method would 
be cleaner:

  class MyStruct
    def self.inherited(subclass)
      subclass.foo = {}
    end

    def self.foo=(v)
      @foo=v
    end

    class << self; protected :foo=; end
  end

But the former code gets the job done with the minimum of fuss.

-- 
Posted via http://www.ruby-forum.com/.