From: "Mauricio Fernández" <batsman.geo@...>
Date: 2003-05-13T02:00:09+09:00
Subject: Re: Overriding methods changes visibility?

On Tue, May 13, 2003 at 01:34:06AM +0900, Chris Pine wrote:
> Is this right?  I wouldn't expect the visibility to change unless I
> specified that it should.
> 
> 
>   irb(main):001:0> class Foo; def foo; end; private :foo; end
>   => Foo
>   irb(main):002:0> class Bar < Foo; def foo; end; end
>   => nil
>   irb(main):003:0> Foo.new.foo
>   NoMethodError: private method `foo' called for #<Foo:0x400cef7c>
>           from (irb):3
>   irb(main):004:0> Bar.new.foo
>   => nil
> 
> 
> Is there a way to say "this method is private, and if you override it, it's
> still private"?
batsman@tux-chan:/tmp$ expand -t2 af.rb

class Foo
  def foo
  end

  class <<self
    def method_added(meth)
      _old_private meth if @@__privates__.include? meth
    end

    alias_method :_old_private, :private
    def private(*args)
      args.each do |x|
        @@__privates__ << x unless @@__privates__.include? x
      end
      _old_private(*args)
    end
  end

  @@__privates__ = []
  private :foo
end

class Bar < Foo
  def foo
    p "foo"
  end
end

Bar.new.foo
batsman@tux-chan:/tmp$ ruby af.rb
af.rb:30: private method `foo' called for #<Bar:0x401a0f64> (NameError)

Cleaner packaging of this in a module (to be used w/ 'extend') left as
an exercise for the reader (I've done this too many times to find it
really exciting :-| )

You'll have to use class instance variables and supporting singleton
methods if you don't want derived classes to be able to specify the
behavior of the superclass. I'll post it if asked to :)

-- 
 _           _                             
| |__   __ _| |_ ___ _ __ ___   __ _ _ __  
| '_ \ / _` | __/ __| '_ ` _ \ / _` | '_ \ 
| |_) | (_| | |_\__ \ | | | | | (_| | | | |
|_.__/ \__,_|\__|___/_| |_| |_|\__,_|_| |_|
	Running Debian GNU/Linux Sid (unstable)
batsman dot geo at yahoo dot com

The bug system is not a release-specific entity.  Users of
Debian 1.3.1 use the same bug tracking system as users of hamm.
	-- James Troup <troup@debian.org>