On Wed, May 26, 2010 at 4:36 PM, Reinier Zwitserloot <reini...@gmail.com>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 <rakesh.mailgro...@gmail.com> 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 <michael.ne...@gmail.com> > 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 <reini...@gmail.com> 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 javapo...@googlegroups.com. > > >> To unsubscribe from this group, send email to > javaposse+unsubscr...@googlegroups.com<javaposse%2bunsubscr...@googlegroups.com> > . > > >> 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 javapo...@googlegroups.com. > > > To unsubscribe from this group, send email to > javaposse+unsubscr...@googlegroups.com<javaposse%2bunsubscr...@googlegroups.com> > . > > > 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 javapo...@googlegroups.com. > To unsubscribe from this group, send email to > javaposse+unsubscr...@googlegroups.com<javaposse%2bunsubscr...@googlegroups.com> > . > 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 javapo...@googlegroups.com. To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
