On Wed, Mar 21, 2012 at 7:52 AM, Charles Oliver Nutter
<head...@headius.com> wrote:
> This *almost* worked, but changing the order just moves the problem
> around. If I make it search for do_it before doIt, that makes a Ruby
> do_it work, but if you implement doIt in Ruby it fails the same way
> (because it finds the do_it we created for the interface module).
>
> Given that the methods on interface modules aren't really meant to be
> called directly, perhaps we could skip adding the aliases? That would
> mean the interface would only list doIt and not do_it in its method
> list, but it would make the reordering work.
Another wrinkle...if you don't define *any* name for an interface's
impl method, it should dispatch to method_missing. I fixed that by
having the dummy methods on the interface always dispatch to
method_missing, since if you hit them it means you have not
implemented the method yourself.
That brought up yet another issue...if the implementation of the
method comes *above* the interface, like in the following example, we
will assume the ancestor class's Ruby method is going to get picked
up. Because we have the interface module in the hierarchy, that's not
the case, so we need to ensure we bind the method below the interface
if that's the nearest signature.
public class Foo {
public void bar() { ... }
}
public interface Bar {
public void bar();
}
public class SubFoo extends Foo implements Bar {
// because Foo implemented the signature necessary for bar, the
interface comes *lower* in the hierarchy than the implementation. We
need to force the Ruby version of "SubFoo" to bind its own dispatcher,
so we don't hit the interface module's stub
}
Complicated.
- Charlie
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
