Virtual Extension By Inversion of Responsibility (Second Draft)

[Reinier Zwitserloot]

While I agree with your stance that its preferable for 'magic' to be as
obvious as possible, I'm not sure its warranted here; method resolution is
already quite 'magical' - in fact, resolution is generally mentioned as the
most complex thing javac's resolution phase has to do (and the resolution
phase is generally considered the most complicated of all the phases).

For example, resolving "foo(a, b)" requires first resolving the types of a
and b against all methods available (including parent types) in the
compile-time type of foo's receiver, which may involve picking between
several overloaded methods. Then encoding that specific method in the class
file. Then, at runtime, this method signature undergoes virtual lookup,
where it may end up in an implementation that didn't even exist when the
original author of "foo(a, b)" wrote that code. This isn't much different
from the idea that foo(a, b) ends up resolving to an extension method, and
therefore using an alternative invoke symbol is perhaps overkill.

I'm not exactly opposed to it on principle, but I'm a bit concerned that
we'd be "spending" the -> symbol on this. As you said, we might want to keep
it available to e.g. add dynamic dispatch at some point.

--Reinier Zwitserloot



On Fri, Jun 18, 2010 at 6:59 PM, Lawrence Kesteloot <lk at teamten.com> wrote:

> Collin wrote:
> > For that matter replacing -> with a . would be even more elegant, if
> possible.
>
> The -> was my favorite part of your proposal. I want to require as
> little context as possible when reading code. If magic is happening, I
> want to know about it.
>
> Also, presumably if you're writing code inside a class Foo that has an
> extension method, with your proposal you'd have to write something
> like:
>
>    this->forEach(...);
>
> It would be extra weird if you got rid of -> and I were allowed to just
> write:
>
>    forEach(...);
>
> and have the system magically insert "this" as the first parameter.
>
> A better reason to avoid -> is that it might be better used for
> dynamic dispatch.
>
> Lawrence
>
>