On Wed, May 26, 2010 at 5:29 PM, Kevin Wright <[email protected] > wrote:
> There's *some* merit in objecting based on complexity I don't see the difference between anon classes and closures from a complexity-standpoint if we omit non-local returns and control flow. > > Why must it always be the case (in Java at least) that new functionality so > often seems to come with a whole bucketload of new boilerplate as well? > Other languages have already shown us that this needn't be the case, and > that features can be combined to offer even more elegance then either one by > itself. > Right now all we can do is to put lipstick on the pig :/ > > The enhanced-for loop was a step in the right direction, allowing me to > write smaller and more elegant code. > Generics, on the other hand... > yeah :/ > > > > > On 26 May 2010 15:41, Viktor Klang <[email protected]> wrote: > >> >> >> On Wed, May 26, 2010 at 4:36 PM, Reinier Zwitserloot >> <[email protected]>wrote: >> >>> Rakesh, as I already said, closures itself are in. Folks like you that >>> think generics sucked and closures are too complicated lost. >>> Fortunately. >>> >> >> Hehe, :-) >> >> >>> >>> On May 26, 11:42 am, Rakesh <[email protected]> wrote: >>> > I recently read Coders At Work and in the interview with Joshua Bloch, >>> > he pretty much inferred that generics may not have been a good thing >>> > because of the complexity it produced. >>> > >>> > If generics had been used to restrict types in collections, fine but >>> > people were using the <? extends Blah> and <? super Blah> too much >>> > making things more complicated. Add to this the reification issue >>> > mentioned previously. >>> > >>> > Personally I think a language change should only be introduced if it >>> > reduces the complexity (sometimes boiler plate isnt the end of the >>> > world as long as you know what it does). I suspect closures will end >>> > up being the next generics debacle. >>> > >>> > R >>> > >>> > >>> > >>> > On Wed, May 26, 2010 at 5:23 AM, Michael Neale < >>> [email protected]> wrote: >>> > > Another point brought up I think on the IllegalArgument podcast was >>> > > how these would interact with non java languages - ie if JDK apis >>> > > start using these closures - how will they map to other languages >>> > > model of a closure. >>> > >>> > > On May 26, 12:24 am, Reinier Zwitserloot <[email protected]> wrote: >>> > >> I got the impression from Dick's note on the closure debate, as well >>> > >> as the response from the black hat guy, that there's some confusion >>> > >> about the closure debates. Yes, that's plural. >>> > >>> > >> There's the: "Should Java have closures" debate. This debate is >>> > >> basically over. Mark Reinhold wants it, and convinced enough people >>> > >> within sun (before the oracle take-over). I doubt this will be back- >>> > >> pedalled now. >>> > >>> > >> There's also the: What should it LOOK LIKE debate. This is a complex >>> > >> debate that hits on a gigantic amount of issues, simply because >>> there >>> > >> are a bajillion ways to fit the following requirement set, and not >>> one >>> > >> of them is the obvious right answer: >>> > >>> > >> 1) Make it simple to write block-like constructs in java (simpler >>> > >> than it is now, at any rate) >>> > >> 2) Make sure whatever construct you come up with makes Parallel >>> > >> Arrays nice too (required use case) >>> > >> 3) Make sure whatever syntax you come up with is invalid if >>> compiled >>> > >> with javac 1.6, and that anything written for javac 1.6 does not >>> > >> change in meaning. (backwards compatibility) >>> > >>> > >> There are a bunch of issues which simply have no clear answer, so >>> the >>> > >> debate on all of these is long, complicated, and involves massive >>> > >> introspection of existing java code as well as example "future" java >>> > >> code to see which makes for the better choice. The list is pretty >>> much >>> > >> endless, so I'll just raise some of the major ones: >>> > >>> > >> 1) The 'strawman' of Reinhold at Devoxx allowed something like >>> > >> "Closure foo = whatever; foo();" however, in java, unlike just about >>> > >> every other language with closures, methods and variables are >>> separate >>> > >> namespaces. The above is mixing and matching them; "foo();" >>> currently >>> > >> means: Invoke a method named 'foo'. It does not mean: Do something >>> to >>> > >> a variable named foo. Should we break the separate namespace rule to >>> > >> make closures look more natural (but with a bevy of java puzzlers >>> for >>> > >> when you have methods named foo as well as closure vars named foo - >>> > >> especially because of backwards compatibility), or should we move >>> away >>> > >> form the strawman and use for example foo.invoke() or some other >>> > >> operator such as foo#() to 'run' a closure? Anyone who thinks >>> there's >>> > >> a clear right answer to this is delusional. In practice there's an >>> > >> unclear right answer which is to move away from the strawman, as the >>> > >> effects of making 'someClosure();' work are quite large, and this is >>> > >> in fact the current status quo. The specific syntax for now is: >>> "foo. >>> > >> ();" >>> > >>> > >> 2) What should they look like? The strawman seems clear enough but >>> > >> has its problems when you nest closure types in closure types (param >>> > >> type of a closure is itself a closure) especially if some of the >>> > >> involved closure types throw exceptions. There's also some risk that >>> 1 >>> > >> minor typo results in a baffling error message, as closure type >>> > >> declarations and closure block declarations look very very similar >>> in >>> > >> the strawman. A lot of the discussion back in the BGGA / FCM / CICE >>> > >> days was in fact all about what it looks like, e.g. "I don't like >>> the >>> > >> => thing in BGGA". >>> > >>> > >> 3) How should it be implemented? Reifying the closure types is >>> > >> virtually impossible, as any closure proposal ought to work well >>> with >>> > >> generics, which aren't reified, and there's no room in the agenda to >>> > >> try to reify generics. But without reified closure types, having >>> > >> arrays-of-closures becomes pretty much impossible, and you get the >>> > >> same erasure problems that generics have. There's some discussion on >>> > >> whether or not a form of reification can be added, though the >>> > >> conclusion so far seems to be: No. However, if reification isn't >>> > >> feasible, should closure types be added at all? The CICE proposal >>> > >> makes do without them. For ease of use with existing code, closure >>> > >> types will auto-convert themselves to "single-abstract-method >>> > >> interfaces" already, so with that feature, perhaps closure types >>> > >> aren't needed. Then again that gets annoying with very functionally >>> > >> oriented libraries. What to do, what to do ? >>> > >>> > >> 4) There's also continued debate about time vs. completeness. >>> Certain >>> > >> proposals are way more involved and are basically shot down due to >>> > >> lack of time, but those same proposals do seem to lead to better >>> > >> syntax and a more consistent language, though whether or not this is >>> > >> really true once such a proposal has been fully fleshed out is >>> > >> unclear, partly because there's not enough time to research it. >>> Should >>> > >> java just get closures now, period, even if it won't be as good as >>> it >>> > >> might have been, or should java either delay the release of java7 or >>> > >> move closures up to java8 to provide the time to get to the best >>> > >> possible proposal? >>> > >>> > >> -- >>> > >> You received this message because you are subscribed to the Google >>> Groups "The Java Posse" group. >>> > >> To post to this group, send email to [email protected]. >>> > >> To unsubscribe from this group, send email to >>> [email protected]<javaposse%[email protected]> >>> . >>> > >> For more options, visit this group athttp:// >>> groups.google.com/group/javaposse?hl=en. >>> > >>> > > -- >>> > > You received this message because you are subscribed to the Google >>> Groups "The Java Posse" group. >>> > > To post to this group, send email to [email protected]. >>> > > To unsubscribe from this group, send email to >>> [email protected]<javaposse%[email protected]> >>> . >>> > > For more options, visit this group athttp:// >>> groups.google.com/group/javaposse?hl=en. >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "The Java Posse" group. >>> To post to this group, send email to [email protected]. >>> To unsubscribe from this group, send email to >>> [email protected]<javaposse%[email protected]> >>> . >>> For more options, visit this group at >>> http://groups.google.com/group/javaposse?hl=en. >>> >>> >> >> >> -- >> Viktor Klang >> | "A complex system that works is invariably >> | found to have evolved from a simple system >> | that worked." - John Gall >> >> Akka - the Actor Kernel: Akkasource.org >> Twttr: twitter.com/viktorklang >> >> -- >> You received this message because you are subscribed to the Google Groups >> "The Java Posse" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]<javaposse%[email protected]> >> . >> For more options, visit this group at >> http://groups.google.com/group/javaposse?hl=en. >> > > > > -- > Kevin Wright > > mail/google talk: [email protected] > wave: [email protected] > skype: kev.lee.wright > twitter: @thecoda > > -- > You received this message because you are subscribed to the Google Groups > "The Java Posse" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<javaposse%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > -- Viktor Klang | "A complex system that works is invariably | found to have evolved from a simple system | that worked." - John Gall Akka - the Actor Kernel: Akkasource.org Twttr: twitter.com/viktorklang -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
