On Tue, Aug 18, 2009 at 7:11 PM, Casper Bang <casper.b...@gmail.com> wrote:
> > Yeah well, it depends how you look at it I suppose. I would also claim > generics to be a figment of the JVM's imagination, since you can not > implement Comparable<Integer> and Comparable<BigInteger> due to it > being an emulated construct at the parser level. Well, not parser - type checker. But I know what you mean. Still, Haskell has a construct called "newtype" which creates a type whose representation is exactly the same as another type, but that the type system treats as compeltely different. That might allow you to say that inches are a type distinct from centimeters even though they are both represented with rational numbers. The fact that newtypes are guaranteed to be erased for efficiency's sake doesn't make them any more "figmentary" than any other type. > Other languages with > real generics have no problem with that, in Java all of a sudden you > are going to need anonymous inner classes as dispatch adapters. "Other languages...real generics." C++ of course uses templating to do polyinstantiation (List<Foo> is a different class from List<Bar>) and mangles the hell out of names so you'd end up with compare_$_Integer and compare_$_BigInteger functions (or whatever your compiler does with them). That's all well and good as long as you stick to the same C++ compiler. But try to interop with another C++ compiler or another language like C and you suddenly start wishing all that type information would be erased. It also makes it damn hard to extend C++ with something like Java's wildcards or Scala's existintials and definition site variance. On the JVM side, Groovy has no problem consuming Java even though parameterized types are way beyond it, just try creating a dynamic language that so seamlessly interops with C++. So, point 1: erasure aids in interop and flexibility. In Haskell implementations are pretty free to do what they want but they tend to erase most types, except perhaps in distinguishing what Java people would call "primitives." Haskell allows overloading but does it through a mechanism called a "type class" which is usually (though not always) implemented with dictionary passing (you can think of this as being somewhat like passing around a strategy object...sorta). So, point 2: different language semantics make erasure more palatable, and in Java different programming styles make it more or less palatable. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
