Generics have 3 big issues (from memory) - Having specified the type parameters on declaring a variable, they must then be repeated when instantiating it.
- Co/Contravariance (i.e. ArrayList<X extends ParentType>). Not so bad on collections, but a nightmare for more advanced structures where USERS have to get the right balance of <X extends T> vs <X super T>. Error messages here if you get it wrong are often less than helpful. - Interop with non-genericised legacy code - 'nuff said! Full kudos to Google Collections though. They do manage to take away much of the pain from the first two points, though some people would consider the API to be non-idiomatic Java. On 26 May 2010 16:41, Alexey Zinger <inline_f...@yahoo.com> wrote: > Generics are complex (more to produce API than consume), but I don't think > it's fair to say that all it did was add boilerplate. As a consumer of > generified API, I hardly ever see casts anymore (which should count as a > reduction in boilerplate as well as an improvement in type safety -- one of > Java's cornerstones), I don't have to express in comments what is now both a > concrete expression in the code and is picked up by javadoc. It has made > light structural typing convenient (rolling your own Pair-like constructs). > > Alexey > 2001 Honda CBR600F4i (CCS) > 2002 Suzuki Bandit 1200S > 1992 Kawasaki EX500 > http://azinger.blogspot.com > http://bsheet.sourceforge.net > http://wcollage.sourceforge.net > > > ------------------------------ > *From:* Kevin Wright <kev.lee.wri...@googlemail.com> > *To:* javaposse@googlegroups.com > *Sent:* Wed, May 26, 2010 11:29:52 AM > *Subject:* Re: [The Java Posse] Re: "The closure debate is pants" - No, no > it isn't. > > There's *some* merit in objecting based on complexity > > 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. > > 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... > > > > > On 26 May 2010 15:41, Viktor Klang <viktor.kl...@gmail.com> wrote: > >> >> >> 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<javaposse%2bunsubscr...@googlegroups.com> >> . >> For more options, visit this group at >> http://groups.google.com/group/javaposse?hl=en. >> > > > > -- > Kevin Wright > > mail/google talk: kev.lee.wri...@googlemail.com > wave: kev.lee.wri...@googlewave.com > 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 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. > > -- > 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. > -- Kevin Wright mail/google talk: kev.lee.wri...@googlemail.com wave: kev.lee.wri...@googlewave.com 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 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.
