function types syntax

[Zdenek Tronicek]

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

This cannot be fixed. The problem is inherent. Or do you have any proposal?
(Except reified generics which solves it).

Z.
-- 
Zdenek Tronicek
FIT CTU in Prague


Osvaldo Doederlein napsal(a):
> 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
>>
>>
>>
>
>