function types syntax

[Osvaldo Doederlein]

Hi,

2010/1/6 Mikael Grev <grev at miginfocom.com>

> The discussions on this list almost always spiral down the purity path,
> making sure that every little 0.1% of use cases are handled for every
> possible situation. What we instead should do is to create a syntax and rule
> set that works really smooth for 95% of the use cases and simply make the
> compiler forbid the last 5% for now. Then we should have a plan for Java 8
> to polish the syntax to cram a few more percent out of the solution (and it
> is important that this is communicated directly for the release of Java 7
> closures).
>

You mean, like we fixed the 5% of important generics issues (e.g.
warning-free new X<T>[]) in JDK 6? Oh, no we didn't; like we are fixing them
now in JDK 7? Nope... perhaps in JDK 8? Some release before I retire?...

(Just for some perspective. Yes, there's the diamond operator in JDK 8, but
that's tiny - it doesn't even completely solve one particular issue (excess
of verbose declarations), a full fix for this would require more aggressive
enhancements - typedefs, generalized type inference, whatever.)

A+
Osvaldo


>
> At least this is how I see it. And I mean no disrespect to purists.
>
> Cheers,
> Mikael Grev
>
>
> On 6 jan 2010, at 18.14, Lawrence Kesteloot wrote:
>
> > On Wed, Jan 6, 2010 at 3:41 AM, Zdenek Tronicek <tronicek at fit.cvut.cz>
> wrote:
> >> So far I thought that we all have the same priorities for closures
> syntax:
> >>
> >> - readability (they are easy to understand),
> >> - intuitiveness (one does not have to learn them for weeks),
> >> - completness (the syntax proposed should involve all the use-cases).
> >> [- compatibility]
> >>
> >> Anything else is far less important.
> >
> > You forgot "correctness", which is actually at the top. I do not want
> > readable syntax at the expense of  a broken compiler. Having to
> > implement complex features like closures and generics in half a dozen
> > compilers and pseudo-compilers will decrease the chance of correctness
> > and portability. (If you get a chance, read through the javac sources
> > to see just how much incomprehensible code is littered throughout to
> > get generics to work. It's frightening. When I added list
> > comprehensions, the bulk of my frustrations were with getting the
> > feature to work with generics, despite the fact that I was working at
> > a level where they were supposed to have already been erased.)
> >
> > To put this another way, imagine the GWT project being started after
> > 1.7 is out, rather than when 1.4 was out. Would they have:
> >
> > 1. Aimed for 1.4 compatibility, guaranteeing that none of their active
> > code could be compiled (because of 1.5 features, generics, and
> > closures).
> > 2. Aimed for 1.7 compatibility, making their task even more daunting.
> > 3. Scrapped the whole project.
> >
> > I suspect 3, though of course we'll never know.
> >
> > I'm not arguing to scrap closures. I'm arguing against the repeated
> > arguments on this list that Java == JDK and as long as we have a
> > single working implementation, then we're done.
> >
> > Lawrence
>
>
>