light weight types
in [Java Help]
|
Prev: Putting passwords in a properties file?
Next: Interview
From: Mike Schilling on 11 Oct 2009 01:59 Peter Duniho wrote: > 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. What follows is largely hypothtiecal, as the only code I've written that uses generics is really toy code intended mostly to help me use to learn generics: The large body of code I maintain at work has to run in 1.4 environments, so generics are not an option there. When it becomes possible to start using 1.5 features, I'm going to do so, both in new classes and when maintaining old classes. And the fact that I can say List<MyClass> newList = (List<MyClass>)exisitngList; // Safe, since I know what this list really contains for (MyClass mc : newList) { ... } will come in very handy. Modifying all the framework methods that return currently List to return NewFangledGenericList would not have been feasible. That is, the actual situation allows me to introduce generics incrementally; this seems to me to be very worthwhile.
From: Patricia Shanahan on 11 Oct 2009 02:17 Peter Duniho wrote: > 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. .... > 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. Would it have taken much time? Couldn't one do something like: public interface Map extends GMap<Object,Object>() public class HashMap extends GHashMap<Object,Object>() etc. The generic version would have needed a name or package change, as well as the changes that had to be done anyway. The compatibility class would be the generic class bound to Object. Patricia
From: Peter Duniho on 11 Oct 2009 02:20 Mike Schilling wrote: > [...] And the fact that I can say > > List<MyClass> newList = (List<MyClass>)exisitngList; // Safe, > since I know what this list really contains > for (MyClass mc : newList) > { > ... > } > > will come in very handy. But IMHO not really a good idea. Generally speaking, that code example doesn't demonstrate any real advantage of using generics. You could just as easily cast each collection element before you use it, as cast the entire collection. > Modifying all the framework methods that > return currently List to return NewFangledGenericList would not have > been feasible. Infeasible, agreed. But neither should anyone do that, even in the hypothetical world where Java generics don't erase type. Lacking type erasure, generics would have had to be wholly separate from already-existing types. There would be no work at all involved in fixing already-existing types or their methods, because that work would be ill-advised (think of all the legacy code that would break, for one). > That is, the actual situation allows me to introduce > generics incrementally; this seems to me to be very worthwhile. Just as type erasure may well have saved some significant work in the Java framework (by avoiding the need to reimplement collection classes), so too may it save you some time in the short-run by allowing you to mix up your code that uses generics with code that doesn't. But in the long-run it's my opinion this is a false savings (maintenance may be harder as it's less obvious where the lines are drawn in your code), and in any case optimizing for the transition at the expense of the broader non-transitional design doesn't seem like a good idea to me. YMMV. :) Pete
From: Steven Simpson on 11 Oct 2009 05:15 Patricia Shanahan wrote: > Peter Duniho wrote: >> 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. > > Would it have taken much time? Couldn't one do something like: > > public interface Map extends GMap<Object,Object>() > > public class HashMap extends GHashMap<Object,Object>() If you could, wouldn't it alternatively be possible to get the compiler to regard an unadorned Map as Map<Object,Object>, rather than warning about it? -- ss at comp dot lancs dot ac dot uk
From: Patricia Shanahan on 11 Oct 2009 08:57
Steven Simpson wrote: > Patricia Shanahan wrote: >> Peter Duniho wrote: >>> 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. >> Would it have taken much time? Couldn't one do something like: >> >> public interface Map extends GMap<Object,Object>() >> >> public class HashMap extends GHashMap<Object,Object>() > > If you could, wouldn't it alternatively be possible to get the compiler > to regard an unadorned Map as Map<Object,Object>, rather than warning > about it? > I assume that alternative was considered, and rejected. If they had kept the non-generic interfaces and provided new ones for generics, it would have been a good choice. Generally, when I change one of my classes to use generics, I intend to make the corresponding changes in all uses, and want to be warned of any failure to do so. Patricia |