Hi --

On Sun, 24 Jul 2005, Trans wrote:

> 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 think that any time you do:

   def f
     f
   end

or equivalent, you've decided you want an infinite loop.  I don't
think any language design feature that intervenes and "fixes" that for
you would be a good one.  (It would make recursion difficult, among
other things.)

> 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 ;-).

It sounds like you want multiple levels of super, so that you can get
at an arbitrary previously-defined version of a given method (not just
the next one up in the lookup chain).  I'm not sure whether this can
be done in an elegant and scaleable way, or whether it's too specific
a use-case for that.


David

-- 
David A. Black
dblack / wobblini.net