light weight types
in [Java Help]
|
Prev: Putting passwords in a properties file?
Next: Interview
From: Patricia Shanahan on 10 Oct 2009 16:12 Mike Schilling wrote: > Peter Duniho wrote: >> On Sat, 10 Oct 2009 00:05:37 -0700, Mike Schilling >> <mscottschilling(a)hotmail.com> wrote: >> >>> 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.) >> Though, .NET illustrates that an alternative approach would have >> been >> to simply create a new, parallel group of classes supporting >> generics, rather than to insist that the old classes be reusable via >> generics. > > It's technically feasible, sure, but given the amount of existing Java > code when 1.5 was introduced, imagine the dumbfoundment with which a > new and incompatible set of, e.g. collections classes (and, far worse, > collection interfaces) would have been greeted. I think it would have made migration a whole lot easier, and the interface complexity could have been handled by having a consistent naming scheme and exactly parallel classes. I faced a nasty dilemma getting to generics. In order to get really familiar with them, I needed to start working in a generics-supporting environment. I could not make the decisions on how to adjust existing code until I got that familiarity. I was faced with about a hundred warnings, and ended up doing a blanket suppression of generics-related warnings while I got my feet under me. Now consider the alternative. All my existing code would have remained warning free. I would have started using the new classes for new code. As I learned my way around generics, I would have including switching to generics in my refactoring passes over code I was changing. The long term aim would have been to remove all uses of the non-generic collections, but I could have done it in a controlled, orderly fashion, with warning-free code at every step. Patricia
From: Arne Vajhøj on 10 Oct 2009 21:47 Mike Schilling wrote: > 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.) Java could have gone for java.util.generic ! Arne
From: Arne Vajhøj on 10 Oct 2009 21:49 Mike Schilling wrote: > Peter Duniho wrote: >> On Sat, 10 Oct 2009 00:05:37 -0700, Mike Schilling >> <mscottschilling(a)hotmail.com> wrote: >> >>> 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.) >> Though, .NET illustrates that an alternative approach would have >> been >> to simply create a new, parallel group of classes supporting >> generics, rather than to insist that the old classes be reusable via >> generics. > > It's technically feasible, sure, but given the amount of existing Java > code when 1.5 was introduced, imagine the dumbfoundment with which a > new and incompatible set of, e.g. collections classes (and, far worse, > collection interfaces) would have been greeted. I make the opposite conclusion from the same fact. All the existing code resulted in a gazillion of compiler warnings due the decision to use the same classes. I would have preferred new classes. Arne
From: Arne Vajhøj on 10 Oct 2009 21:59 Lew wrote: > 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. No difference. The cast is just done somewhere else in the code with type erasure. > 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. Generics without type erasure is not catching fewer errors at compile time. It has the exact same compile time type safety. It only adds some additional capabilities in the code. > It is true that certain shortcomings exist with the erasure approach, > but the advantages make it worth it. I don't think so. Less functionality, no performance benefits and no stricter compile time checks. It is purely a compatibility issue. Arne
From: Peter Duniho on 11 Oct 2009 01:10
Mike Schilling wrote: > Peter Duniho wrote: >> >> Though, .NET illustrates that an alternative approach would have been >> to simply create a new, parallel group of classes supporting >> generics, rather than to insist that the old classes be reusable via >> generics. > > It's technically feasible, sure, but given the amount of existing Java > code when 1.5 was introduced, imagine the dumbfoundment with which a > new and incompatible set of, e.g. collections classes (and, far worse, > collection interfaces) would have been greeted. As Patricia and Arne, I don't see the problem. If anything, by overloading existing classes, they created problems for legacy code unnecessarily. For new code, I don't see how it would matter that the new generic classes were an entirely new class, rather than taking advantage of an existing class. To the coder, it's all-new one way or the other. I agree that since generics showed up earlier in the lifetime of .NET, it was an easier, simpler transition. But I don't think that correlates much, if at all, with the question of whether to have type erasure or not. That is, while reuse of the existing classes might have been the motivation for erasing types in generics, it's not clear that primary goal of reusing the existing classes really gained much in the long run. I think in the short run, the big win was not having to reimplement all those classes. And to be sure, I've no doubt it saved someone a fair amount of time. But that cost is, in the long run, relatively small, and the consequences are significant. Pete |