David A. Black wrote:
> Hi --
>
> Please... no creeping punctuation :-)  I think this concept of local
> is clearly in the same group as private/protected/public, and it would
> therefore make sense to have it declared.

I tend to agree.

> I'm actually unconvinced of the desireability of it.  While it's
> reasonable to assume that people may not know every instance variable
> that's been used, I think if you're inheriting from a class the burden
> is on you to know what that class's instance methods are.  It's hard
> to imagine a case where it would be otherwise.  (Or is there some
> other scenario where you would want this?)

I do have a scenario, but in looking at it agian in detail I realize
that only local instance methods as a COMPLETELY SECONDARY NAMESPACE
might be enough to deal with it. Here's the problem: I want to create
an abstraction such that I have no need to be concerned with method
name clashes. The basic example is if I have created a reusable module
A and wish to include it in a subclass of some given class C (Keep in
mind A is created independently and without prior knowledge of C):

  module A
    def f
      "'"
    end
  end

  class C
    def f ; "f" ; end
  end

  class CA < C
    include A
    def f
      f + super
    end
  end

There's a problem b/c A#f is not being called and we get the infinite
loop.

I was thinking that a seperate local method namespace could be used to
solve this, something like:

  class CA < C
    local_include A
    def f
      f + super
    end
  end

So that the methods of module A are included in CA as local and local
methods would have priority, so in this case the call to #f would go to
the right place. To specifically call the public method one would have
to use self.f. But I must confess this has some serious shortcomings,
which makes me think the _call_ mechinism is a much better way to go
--it doen't prevent the inhertiance but maybe that's a good thing, and
as you say the burden is on the inheriter (unlike real life ;-).

T.