Chris Carter wrote:
...
> I have been following this whole dicussion, and I think it is time to
> put my two cents in, and summarize it.
> 
> We started not liking how #send would call private methods. and we
> need it to not call them, but wait we need soemthing so we can call
> those private methds.  The most commonly suggested method: #send!  But
> #send still causes namespace issues.  The ultimate solution!...lots of
> underscores.  We hate those too, hrm.  Lets add a new super
> class/module/object/thing to the mix, called a Pervasive.  When we
> need something not unique to a class we call it with Pervasive.method
> obj.  Wait, then we do Pervasive.new(Foo, :args) every time, and we do
> Pervasive.class obj a lot too.  This is super ugly, probably breaks
> encapsulation, etc...  The solution, give the classes those methods,
> and make them overriable, and also allow access to the object through
> the Pervasive.  Problem here though, when writing a library we won't
> know that someone overrode a method somewhere else in the chain, so we
> are stuck using the Pervasive a lot anyway.  Why this isn't a problem
> now you might ask?  Because we don't have the Pervasive, so people are
> less willing to override those methods.  We still won't have a good
> looking #send that calls private methds.  Well, we will, but it needs
> a name.  I am willing to write up the RCR on this one.

Thanks for the summary, Chris.

Could this be solved by having a hash of method objects, accessed 
through a method on Kernel?

pm = Kernel.pervasive_methods

m = pm["class"] # => #<UnboundMethod: Object#class>
"foo".bind(m).call #=> String

The values in the hash are always the original implementations.

No new syntax or modules, just one new method.

-- 
        vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407