From: gwtmp01@...
Date: 2005-07-24T22:59:20+09:00
Subject: Re: Local Instance Methods


On Jul 24, 2005, at 8:37 AM, David A. Black wrote:
> 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 tend to view this as way of minimizing namespace pollution and
possible naming clashes.

What if I want to include two different modules from two different
sources and they both use a common method and/or instance variable
name?  How do I resolve that?  It isn't enough to rename one of the
methods because internally the module won't be calling the correct
method.

If the name clash is with code I've written I can just use different  
names
in my code but when merging code from different sources that isn't
necessarily possible without editing the sources.

Private instance methods/vars would not remove this problem but it
would minimize the namespace occupied by a module/class.

Eiffel supports "relative naming" such that when inheriting you
can alter the names of the inherited features to avoid the name
clashes and/or enhance readability.  Could Ruby have something like:

     module Helpful
         def update; end
         def private_method;
             do_something
             update
             do_somethingelse
         end
     end

     class A
         include Helpful, {:update => :helpful_update}
         def initialize(target)
             target.add_observer(self)
         end
         def update
             # this is used for the Observer protocol
         end
         def use_helpful
             helpful_update    # used for something else
         end
     end


The idea of the hash on include is to change all definitions and
calls of update *within* the module Helpful to be helpful_update
instead.  The problem is that I don't think you can do this statically.
You would have to keep track of this information and use it during
method lookup somehow.



Gary Wright