Virtual extension methods - syntax options

[Reinier Zwitserloot]

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. In other words, moving forward on
implementing "method.()" doesn't make switching this particular aspect any
harder than it would be today. Hence there is no point to start debate on
this. Furthermore, syntax clearly tends towards the opinion part of the
spectrum; it is far more difficult to prove that a certain syntax is better
than some other syntax, compared to, say, showing that a certain
implementation strategy is faster on the current VM than some other
strategy, or that some shortcoming is acceptable or not ("provable" one way
or the other by writing a search tool that'll find occurrences in source
repositories). Language discussions are difficult enough already.


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.

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

Whether a certain comment on syntax falls in the 'pointless painting of the
bikeshed' domain or 'fruitful lateral thinking' domain is an exercise for
the reader.

--Reinier Zwitserloot



On Sat, Jun 12, 2010 at 2:07 AM, Howard Lovatt <howard.lovatt at gmail.com>wrote:

> *Brian Goetz* brian.goetz at oracle.com
> <
> https://mail.google.com/mail/?view=cm&fs=1&tf=1&to=lambda-dev%40openjdk.java.net&su=Virtual%20extension%20methods%20-%20syntax%20options&In-Reply-To=AANLkTimJotG3ql2j5ckvAoLBIFqFjuKC8C30oVBlHVgb%40mail.gmail.com
> >
>  *Fri Jun 11 07:59:35 PDT 2010 wrote:*
>
> >The answer is neither: the syntax is not set in stone, but we strongly
> >discourage ongoing discussions of syntax :)
>
> Some sentiment along this line keeps on getting invoked. Since various
> discussions keep on coming back to the syntax, the lambdas themselves,
> extension methods, exception transparency, etc., I would suggest it is more
> important than you give it credit for. The syntax discussions can occur in
> parallel to the implementation discussions; in fact I would say that this
> is
> ideal, since if a workable syntax cannot be found there is no point in
> continuing with the implementation.
>
> To make this concrete; I would suggest that if the syntax of variance (wild
> cards) was throughly investigated before the implementation or in parallel
> with the implementation then we wouldn't have variance today (which the
> wider community, and myself, think would be a good thing).
>
> A good language or language feature needs to balance not only the
> implementation but also the burden on the programmer. Do you not see the
> irony in arguing that syntax isn't important on a lambda discussion group;
> lets face it, one of the primary motivations for lambdas is
> the unwieldy syntax of inner classes?
>
> On a more philosophical point, stifling discussion is rarely fruitful. If
> people want to discuss something let them. I would only draw the line if
> the
> discussions were abusive or wildly off topic.
>
>  -- Howard.
>
>