Virtual Extension By Inversion of Responsibility (Second Draft)

[Collin Fagan]

Neal -

I'm sorry I haven't gotten back to you. I've been on vacation and haven't
been online. I'll try and build some more complicated generics examples. I
also have a keyword version of the proposal.

Collin

On Fri, Jun 18, 2010 at 8:24 PM, Reinier Zwitserloot <
reinier at zwitserloot.com> wrote:

> 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
> >
> >
>
>