From: "David A. Black" Date: 2005-07-25T00:38:03+09:00 Subject: Re: Local Instance Methods 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