Re: new method dispatch rule (matz' proposal)

On 6/17/07, David Flanagan <[e-mail]> wrote:
> Steven Lumos wrote:
> > Maybe I'm confused, which of these are you talking about?
> >
> > class A
> >   def m; @f(); end
> >   def @f; true; end
> > end
> >
> > class B < A
> > end
> >
> > B.new.m  #=> Error: The mighty class author requires that you
> >              reimplement @f.
> >
> > or
> >
> > class B < A
> >   def @f; false; end
> >   #=> Error: The mighty class author forbids you to reimplement @f
> > end
> >
> > Steve
> >
> >
>
> Steve,
>
> I don't intend either of those, really.  My proposal is that the method
> @f would be completely local to the defining class.  There is no
> inheritance of these hypothetical methods, and so the class hierarchy is
> irrelevant.  If you try to invoke @f in a class B that does not define
> @f you get a NoMethodError or whatever. And you can define @f in a class
> B regardless of what is defined in the superclass, so you'd never get an
> error message like your second one.
>
> I think that the intent of the Matz's proposal from 6 months ago was to
> acheive something like this, and there seemed to be some consensus that
> that would be a good thing.  What I'm adding with my proposal here is an
> explicit punctuation prefix that would, I think, make it possible to
> implement this kind of local method without altering the method name
> resolution algorithm that is currently used for private methods.

One worry I have about the prefix is how would one include a module as
local-private? Ie.

  module M
    def x; ...; end
  end

  class R
    include_as_local M
  end

Would #include_as_local change the names of M's methods somehow?

T.