Virtual extension methods - syntax options

[Jesse Kuhnert]

You know the old saying "talk is cheap" probably directly applies here.

Neal has the BGGA implementation, Oracle has their current
in-development version. (although to be fair it sounds like the minds
at oracle/Neal both have years and years of formal training and real
field experience doing this..even with lowly general API design I've
rarely found many "easy" large changes where backwards compatibility
and public API use are involved..ok maybe never ;) )

Since you are the only one convinced of how easy it is, why don't you
just show us? Any more talk at this point on your part without
evidence to back it up would surely just make the talker look more and
more foolish and possibly troubled..

On Wednesday, June 16, 2010, Reinier Zwitserloot
<reinier at zwitserloot.com> wrote:
> 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
>>
>
>