Josh Cheek wrote in post #1103951:
> On Mon, Apr 1, 2013 at 1:16 AM, Igor Pirnovar <lists / ruby-forum.com>
> wrote:
> You can't hide methods from subclasses.

I, know you cannot hide methods from subclasses in Ruby. On my quick
initial reading of your first post in this thread, I had an impression
you wanted to do so, as it looked, by imposing your own, BTW, rather
dubious convention, to use {{self}} on all instance methods defined in a
class in which they were defined. Insisting to use {{self}}, would
indeed, prevent a subclass to access a private method of a superclass,
while calling protected or public methods in superclasses this way,
would not!

  ----------------------------------------------------------------------
  class A;def who; base;end; private;def base; puts "Class A";end; end
  class B<A;def who; self.base;end; def base;puts "B:overriden";end; end
  class C<A;def who; self.base;end; end
  a = A.new
  a.who    #=> Class A
  b = B.new
  b.who    #=> B:overriden
  c = C.new
  c.who    #=> Exception NoMethodError
  ----------------------------------------------------------------------

Hence, there is a way, to shield access to inherited methods, providing
you obey your self-imposed convention.

> It's not clear to me what you mean about variables being public.

You have access to any instance variable in any class in the inheritance
hierarchy, as long as you do not shield a variable by defining it with
the same name as one in a superclass:

  ---------------------------------------------------------------------
  class A; def initialize; @av="A";end; private; attr_accessor :av; end
  class B<A; def private_instvar_of_super; puts "@av=#@av"; end; end
  b = B.new
  b.private_instvar_of_super  #=> @av=A
  ---------------------------------------------------------------------

But, you seem to know this, as you obviously know for the benefits of
using accessors, only for some reason, you would not see this
unrestricted instance variable visibility and access as public?

> I rarely worry about my Ruby being non-ruby-ish. ....

I never said that Ruby is non-ruby-ish! Non-ruby-ish is perhaps
someone's programming style, and certainly, trying to make instance
variables (or as, I am sure, you'd correct me, access to them) private
in Ruby, qualifies for such a characterization.

Ruby allows you to be as free or as strict as you wish! It does not help
you too much to enforce your whims, or your own programming conventions,
though. There is absolutely nothing preventing you to accomplish the
required flexibility "to implement your public methods by using private
data" or "frequently change variable names, move things around, change
implementations, etc." In fact I applaud you to find a way to turn all
accessor methods to behave almost as if they were private, by using
protected instead.

Also, converting classes and structures back and forth is highly
unreliable practice in Ruby, particularly because of the inconsistencies
when using accessor methods, which may fail to work in structures. If
you wish to enjoy Ruby oo paradigm, you better think twice if you really
want to use structs. But, I guess, you'd have to be the "Rubyist", to
know this?

I do not think, your presenting yourself as a cavalier, who believes he
is entrapped in some fictitious Ruby constraints, is an accurate
description. I wish one day you'd realize, Ruby is cavalier to you
instead.

All the best, igor

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