Virtual extension methods - syntax options

[Reinier Zwitserloot]

You clearly didn't understand my point. Of course I know "closure()"
requires lots of work; I was the one originally highlighting again and again
how difficult it is to make "closure()" work on your pet closure mailing
list (closure-dev) a few months ago.

What I said was that whatever effort is required to make "closure()" work,
proceeding for now with "closure.()" will not increase that workload. None
of the steps taken in implementing the straw man so far somehow get in the
way of that considerable workload (of writing a spec + implementation of
somehow deciding which namespace is intended anytime the compiler sees
"foo.bar.baz()"). I believe the decision has mostly been made (fortunately)
that foo() will NOT be the closure invocation syntax. Nevertheless, for
those who strongly feel foo() is the right way forward, right now is
probably not the best of times to raise this point. We've got bigger fish to
fry right now, things that cannot wait. Either way, a syntax discussion on
that topic, especially without prototypes, doesn't seem to be nearly as
fruitful as e.g. sorting out checked exceptions vs. closures, which looks
like quite a bit of mutually exclusive work between the current 3 proposals.


I've written down an alternative exception transparency proposal in this
mailing list based on pure/impure closures. It even lists the constraints.
It does not support exception transparency in certain seemingly rare use
cases, which is a hefty price to pay, perhaps, but, on the other hand, it
gets rid of a _LOT_ of complexity and syntax. Your continued absolute
position on this remains wholly unsupported. I presume Brian, Mark, Alex,
and friends do not take the gospel of Neal as enough proof. Perhaps you can
show us a set of examples that will suggest that this use case isn't nearly
as rare as I think it is. Either way the decision isn't black and white;
it's a matter of how many use cases are "lost" (can no longer be done
cleanly) compared to exactly how syntactically and semantically complex one
considers the explicit "throws E" concept.

--Reinier Zwitserloot



On Wed, Jun 16, 2010 at 10:50 PM, Neal Gafter <neal at gafter.com> wrote:

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