On 24 June 2011 14:16, Casper Bang <[email protected]> wrote: > > I think type erasure was an error, I would have preferred no generics to > > what we have. I agree though that few languages that claim to have > > properly supported parameterized types do. > > I'm with you on that. Erasure introduces an unnecessary duality in the > type-system where you read one thing, but the compiler and runtime > really sees something else! One can not write implements > Comparable<T>,Comparable<U>" because underneath the layer > of lipgloss it really reads "implements Comparable<Object>, > Comparable<Object>" due to the fact that the compiler is really > just injecting down-casts and type-checks plus some extra meta-data > solely for reflection purposes. > > At least in C#, you get what you see, plus they can do a whole lot of > performance optimization and code sharing. There's a decent comparison > at Wikipedia: > http://en.wikipedia.org/wiki/Comparison_of_C_Sharp_and_Java#Generics > > Sometimes it's ok to draw a line in the sand and break with > comparability to fix something, Java could be much much more elegant > and lean today. > > /Casper > >
Unfortunately for you, if you'd have voted for reification back in the day, then we'd be stuck with use-site variance. It's therefore ironic to note declaration-site variance as used by C# and Scala is now thankfully possible precisely because of erasure and the freedom that erasure gives language designers to implement a type system in any manner they see fit! (note: I'm assuming you like C#'s approach, having already mentioned the language). It's not unthinkable that Java might be able to support declaration-site variance at some point in the future, with plenty of backwards compatibility. Again, this is only possible because of erasure. Nor is that the last word on variance, the subject continues to be studied academically, and erasure affords languages the freedom to innovate regardless of the underlying VM. Take this paper, for example: http://www.google.co.uk/url?sa=t&source=web&cd=1&ved=0CBoQFjAA&url=http%3A%2F%2Fwww.cs.umass.edu%2F~jaltidor%2Fvariance_pldi11.pdf&rct=j&q=bivariant%20type%20system&ei=VMUETovgDY2BhQfowuCvDQ&usg=AFQjCNHnayHvMtv1n8Th4u5nMtN5HviHVQ It argues (very effectively) in favour of supporting both use AND declaration-site variance, as well as adding support for bivariance to a language. Personally, I'm rather glad that such possibilites are still open to us, this kind of thing would be far more difficult in C#. All grant you, reification certainly makes some problems appear easier, but it also makes other problems (including optimisations within the JVM) somewhat harder. There's also no problem caused by erasure that can't conceptually be handled without recourse to reification. Far from being a problem it is, in fact, a selling point of Java; offering better performance and greater potential for future innovation on the platform. -- Kevin Wright gtalk / msn : [email protected] <[email protected]>mail: [email protected] vibe / skype: kev.lee.wright quora: http://www.quora.com/Kevin-Wright twitter: @thecoda "My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra -- 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.
