Virtual extension methods - syntax options

[Reinier Zwitserloot]

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