light weight types
in [Java Help]
|
Prev: Putting passwords in a properties file?
Next: Interview
From: Roedy Green on 10 Oct 2009 02:47 On 07 Oct 2009 12:48:41 GMT, Thomas Pornin <pornin(a)bolet.org> wrote, quoted or indirectly quoted someone who said : >this code snippet does not compile: the contents of 'a' cannot be >silently converted to the 'List<Object>' type. Why so ? Because the list >instance does NOT know it element type. Generics work by so-called 'type >erasure' That is one of my conjectures, that type erasure was a wrong-headed idea. It weakened and complicated generics too much. Surely, it is not inherent to the notion that containers should be type safe. Think of it this way. How is an ArrayList different from an array? Basically all it does is automatically grow when it overflows. I could imagine a Java-like language where growing happened automatically to arrays. Why should the ability to grow suddenly require all this additional complexity? Why should Maps (which are a sort of Array with Object indexes) be all that much more complicated that arrays? One way to answer me is to show that the problem is intrinsically complicated, even without type erasure. I don't think we should surrender to this mess without a fight, or at least a good explanation. Part of my skepticism comes from implementing my own language, Abundance, back in the early 80s where growing arrays, maps and files were all handled with the same syntax as arrays. -- Roedy Green Canadian Mind Products http://mindprod.com I advocate that super programmers who can juggle vastly more complex balls than average guys can, should be banned, by management, from dragging the average crowd into system complexity zones where the whole team will start to drown. ~ Jan V.
From: Mike Schilling on 10 Oct 2009 03:05 Roedy Green wrote: > On 07 Oct 2009 12:48:41 GMT, Thomas Pornin <pornin(a)bolet.org> wrote, > quoted or indirectly quoted someone who said : > >> this code snippet does not compile: the contents of 'a' cannot be >> silently converted to the 'List<Object>' type. Why so ? Because the >> list instance does NOT know it element type. Generics work by >> so-called 'type erasure' > > That is one of my conjectures, that type erasure was a wrong-headed > idea. It weakened and complicated generics too much. Surely, it is > not > inherent to the notion that containers should be type safe. Erasure is needed for compatibility with the non-generic version of the type, and that's the only reason it exists. If generics had been present from the beginning, the type parameters would be first-class parts of the type, just as they are for arrays. (And just as they are in .NET, where generics were used only in newly introduced classes.)
From: Lew on 10 Oct 2009 10:54 Roedy Green wrote: > That is one of my conjectures, that type erasure was a wrong-headed > idea. It weakened and complicated generics too much. Surely, it is not > inherent to the notion that containers should be type safe. I like type erasure. It keeps one from the temptation to use genericity as an operational concept as opposed to a declarative one. -- Lew
From: Mike Schilling on 10 Oct 2009 12:08 Lew wrote: > Roedy Green wrote: >> That is one of my conjectures, that type erasure was a wrong-headed >> idea. It weakened and complicated generics too much. Surely, it is >> not inherent to the notion that containers should be type safe. > > I like type erasure. It keeps one from the temptation to use > genericity as an operational concept as opposed to a declarative > one. I almost know what this means, but every time I think I've grasped it, my hand seems to be empty. Could you elaborate?
From: Lew on 10 Oct 2009 12:57
Mike Schilling wrote: > Lew wrote: >> Roedy Green wrote: >>> That is one of my conjectures, that type erasure was a wrong-headed >>> idea. It weakened and complicated generics too much. Surely, it is >>> not inherent to the notion that containers should be type safe. >> I like type erasure. It keeps one from the temptation to use >> genericity as an operational concept as opposed to a declarative >> one. > > I almost know what this means, but every time I think I've grasped it, > my hand seems to be empty. Could you elaborate? As it stands, generics provide a compile-time contract for declarations about type relationships. In order to get run-time behavior, i.e., operational use of type information you need to provide a Class object; type parameters don't permit any run-time operations. The result is that generics provide compile-time assertions that code will not throw a ClassCastException or other type-related problem. Erasure guarantees that this safety carries no run-time overhead. Run-time generics would sacrifice this efficiency and tempt us to patch holes in the type analysis with procedural hacks. Instead of analyzing the types we'd coerce them. Java still lets you do run-time type tricks with a type token (Class object), but type parameters are reserved for assertions about type relationships. This forces us to deal with type problems at compile time. It's a well-known truth that catching and preventing bugs at compile time is far superior to dealing with them at run time. It is true that certain shortcomings exist with the erasure approach, but the advantages make it worth it. -- Lew |