Virtual extension methods - syntax options

[Jesse Kuhnert]

I must have missed it then, my gmail search for "Reiner exception"
only turned up a 60 reply thread conversation stemming from a proposal
Brian put forth.

Maybe if your ideas were more easily summarized in to something that
stands alone it would be easier to consume and reference for
discussion. Possibly even a link? I'm sure it wouldn't be expected to
be a conpletely thorough academic exercise but the realities of the
existing/in process jdk/vm would certainly have to align with what you
wanted to do..as well as the even sneakier forwards compatible
ramifications.


On Wednesday, June 16, 2010, Reinier Zwitserloot
<reinier at zwitserloot.com> wrote:
> As I understand it, exception transparency is still in the "writing a spec" phase. I've written a spec for it. --Reinier Zwitserloot
>
>
>
> On Thu, Jun 17, 2010 at 1:46 AM, Jesse Kuhnert <jkuhnert at gmail.com> wrote:
>
> 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