Ben, James: Ah, we're not talking about scala's dubious choice to use + and - symbols instead of keywords, but about the ability to declare an entire type array-style subtypable in a pinch.
Which uses cases exist for that mechanism other than 'this class is immutable, and therefore won't break under covariance'? Because if that's the only case, I say: Add a rigidly checked immutability modifier to the language itself and automatically make the type covariant across the board. Java doesn't have that many immutable structures and even fewer immutable structures that have a generics parameter. Sure, collections API stuff can be immutable, but the various add methods still exist. They'd throw exceptions, of course, but List itself (the type; java.util.List) could not make a blanket declaration that it won't break under covariance. Therefore, adding this feature would only have been useful if the entire collections API got an overhaul, which, due to backward compatibility reasons, wouldn't happen. That would have also been quite premature, as, if such an overhaul did happen, they'd now need to be overhauled AGAIN to retrofit functional-style methods in combination with closures (well, not now, but java 8, surely). Stuff like map, filter, each, you know the ones. Doing generics, closures, reification, annotations, and varargs all in a single java update is just /slightly/ overreaching. However, if closures do make it into java, and the collections API is overhauled to offer proper immutable versions for everything (I don't see how without starting an entirely new collections API, or completely breaking the existing API) - then adding this feature might be useful. Though, I'd still far rather research if the compiler can figure out by itself if a type is covariant-safe, for example with that immutable modifier I mentioned. You call java 'very verbose' and then you write <? extends Object> instead of <?>? I think the verbosity is more of a personal problem, there. On Jan 29, 12:32 am, Ben Schulz <[email protected]> wrote: > > > 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. > > Reinier, > > I think it's a great idea, you just have to use it in the right spots. > If I recall correctly the example on scala-lang.org was an immutable > list -- obviously a list of Strings is also an immutable list of > Objects; > > ImmutableList<? extends Object> list = new ImmutableList<String>(); > > is very verbose and casting is plain dirty. > > PS: It was an immutable stack:http://www.scala-lang.org/node/129 > > With kind regards > Ben --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
