James, can you elaborate on some of these? Specific questions are inline. > 1) Optional definition site variance. When I want co or contra- > variant type parameters now I have to litter my code with Foo<? > extends Bar> or Foo<? super Bar>. It's so painful I mostly don't > bother making my types as general as they could be.
How would this work? I don't think the scala strategy (cartoon swearing instead of 'extends' and 'super' keywords) is viable. > 2) Some type inference, somewhere, please - without me having to write > static factory methods. Before generics all the explicit type > annotations were mildly irritating. After generics writing > Foo<Bar<Baz, Quux>> foo = new Foo<Bar<Baz, Quux>> is really, really, > really irritating. Amen. Even if you look at the places where java does infer (e.g. static calls), the inference is very mild. Java isn't the right language for extreme inference, but a little more would no go amiss at all. Many languages have solved this problem so there really is no excuse for javac. > 3) Type aliasing (aka typedefs). Same motivation as with type > inference, but type aliases can handle types that can't be inferred. Meh. Complicates the language quite a bit just to work around some problems, never the right motivation for a language update. > 4) Deprecate "primitive" arrays and replace with properly generic type > constructor Array<T>. Make Array<T> invariant so that Array<String> > isn't an unsound subtype of Array<Object>. Not a bad idea in a possible post-reification future but the dichotomy between having Array<T> that *IS* reified and List<T> that is not, is too great. I think having non-null types, or at least non-null primitive wrappers, or even just primitive classes as legal generics parameters, would have been far more useful, so that you can actually have a List<int>. It would be fine with me if there's a special PrimitiveLists.createIntList() method to create them, (well, it's going to be that, or .NET-esque generating the complete generics-using class for each primitive) as long as, post-creation, they are virtually as fast as arrays yet fit the List<T> type. > 5) Root the type hierarchy above object so that primitives are part of > the hiearchy. Maybe. But it would be a shame that the compiler isn't as helpful as it could be in regards to nullity. Probably better solved with .NET- style templating of the class code for each primitive, -or-, added along with full nullity support. > 8) Don't call it "generics." Damage done. Also, only language nuts get hung up on using the proper verbiage. For everyone else, its a massive turn off. One of the many reasons that scala/haskell/lisp using language pedants are never actually listened to and just ignored. Too much jargon. There might be more suitable words, but its of little importance. > you can specify types [in scala] that don't have a no-arg constructor If only Scala was a language that had more features. Like, say, 'class interfaces' that captured constructors and static methods. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to javaposse@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 -~----------~----~----~----~------~----~------~--~---
