Virtual extension methods - syntax options

[Neal Gafter]

On Wed, Jun 16, 2010 at 9:41 AM, Reinier Zwitserloot
<reinier at zwitserloot.com> wrote:
> Joe posted something relevant on the topic just now:
>
> http://blogs.sun.com/darcy/entry/syntax_sin_tax
>
> It's as usual a bit more complicated than this.
>
> Comments along the line of:
>
> * "#void(int, int)" is ugly, we should use: "#(int, int)void" instead!
>
> or:
>
> * "method.()" 'isn't Java' and should either be just "method()" or
> "method.invoke()".
>
> are indeed painting the bikeshed. they ARE pointless, in that now is not the
> time to make these decisions, and it is clear that from the "method.()"
> syntax you can move to either "method()" or "method.invoke()" with the same
> effort all throughout the process.

While this may be clear to you, it isn't true.  Moving to
function.invoke() is easy, but moving to function() requires an
overhaul of the Java namespaces and name resolution rules.  It is the
time to decide which of these approaches will be taken, but my
understanding is that the current decision is that there will not be
an overhaul of the name resolution rules.  That means function() is
ruled out as an option.

> On the other hand, some discussions are focussed around syntax but in such a
> way that NOT changing the outlook becomes more expensive over time. For
> example, blazing forward with the exception transparency proposal as it was
> written (with <throws E> and friends) is a lot of work, which would all have
> to be tossed if the Pure/Impure closures alternative is used instead (which
> is good, then that time can be invested in writing a spec and implementation
> for detecting pure and impure closures!), or lone throws.

Indeed, this is not an issue of syntax, but one of semantics (although
the two options do have different surface syntax too).  So now is the
time to examine such alternatives.  But there is no coherent proposal
for an alternative way of doing exception transparency for us to
consider (I am aware that you don't acknowledge the failures of the
lone throws approach).

> It would all be fair game if the argument "well, we don't have the time to
> do this anymore" is never uttered, but clearly it will (in fact, it already
> HAS, when full reification came up. I get why there's no time for that, but
> it does prove by default that time is a factor).

Are you saying that you and/or Colebourne don't have the time to
specify a coherent alternative that both supports exception
transparency (even in APIs that must store the functions in variables)
and does not undermine exception checking?

Cheers,
Neal