light weight types
in [Java Help]
|
Prev: Putting passwords in a properties file?
Next: Interview
From: Steven Simpson on 11 Oct 2009 09:48 Patricia Shanahan wrote: > Steven Simpson wrote: >> Patricia Shanahan wrote: >>> 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. I was implicitly suggesting that some of the reasons for rejecting "Map is short for Map<Object,Object>" would apply to "Map extends GMap" just as well. > 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. Are you saying that relying on "Map extends GMap" would have warned you any better than "Map is short for Map<Object,Object>"? -- ss at comp dot lancs dot ac dot uk
From: Patricia Shanahan on 11 Oct 2009 10:24 Steven Simpson wrote: > Patricia Shanahan wrote: >> Steven Simpson wrote: >>> Patricia Shanahan wrote: >>>> 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. > > I was implicitly suggesting that some of the reasons for rejecting "Map > is short for Map<Object,Object>" would apply to "Map extends GMap" just > as well. Could you give an example of a such a reason? Note that the reason I listed definitely does not apply to "Map extends GMap<Object,Object>". > >> 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. > > Are you saying that relying on "Map extends GMap" would have warned you > any better than "Map is short for Map<Object,Object>"? > Yes, because I could have left the warning for non-generic use of a generic type enabled. As it was, I had to suppress that warning until I had the time and understanding of generics to change all my previously correct uses of the newly generic java.util types, including Map. Patricia
From: Steven Simpson on 11 Oct 2009 11:44 Patricia Shanahan wrote: > Steven Simpson wrote: >> Patricia Shanahan wrote: >>> Steven Simpson wrote: >>>> Patricia Shanahan wrote: >>>>> 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. >> >> I was implicitly suggesting that some of the reasons for rejecting "Map >> is short for Map<Object,Object>" would apply to "Map extends GMap" just >> as well. > > Could you give an example of a such a reason? Note that the reason I > listed definitely does not apply to "Map extends GMap<Object,Object>". I thought it did, but... >>> 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. >> >> Are you saying that relying on "Map extends GMap" would have warned you >> any better than "Map is short for Map<Object,Object>"? >> > > Yes, because I could have left the warning for non-generic use of a > generic type enabled. As it was, I had to suppress that warning until I > had the time and understanding of generics to change all my previously > correct uses of the newly generic java.util types, including Map. Ah, so, by the GMap plan, anything you leave as Map will raise no warnings, but when you're ready to upgrade some part to generics, you can enable warnings for that specific part by switching to GMap there. Selective warnings are then opt-in, rather than opt-out with an annotation - right? -- ss at comp dot lancs dot ac dot uk
From: Patricia Shanahan on 11 Oct 2009 11:49 Steven Simpson wrote: > Patricia Shanahan wrote: >> Steven Simpson wrote: >>> Patricia Shanahan wrote: >>>> Steven Simpson wrote: >>>>> Patricia Shanahan wrote: >>>>>> 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. >>> I was implicitly suggesting that some of the reasons for rejecting "Map >>> is short for Map<Object,Object>" would apply to "Map extends GMap" just >>> as well. >> Could you give an example of a such a reason? Note that the reason I >> listed definitely does not apply to "Map extends GMap<Object,Object>". > > I thought it did, but... >>>> 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. >>> Are you saying that relying on "Map extends GMap" would have warned you >>> any better than "Map is short for Map<Object,Object>"? >>> >> Yes, because I could have left the warning for non-generic use of a >> generic type enabled. As it was, I had to suppress that warning until I >> had the time and understanding of generics to change all my previously >> correct uses of the newly generic java.util types, including Map. > > Ah, so, by the GMap plan, anything you leave as Map will raise no > warnings, but when you're ready to upgrade some part to generics, you > can enable warnings for that specific part by switching to GMap there. > Selective warnings are then opt-in, rather than opt-out with an > annotation - right? > Yes, that is exactly what I would have preferred. I did not want to add annotations, because I would have had to remove them individually during refactoring when I wanted to make some structure generic. At least disabling the specific warning in Eclipse was easy to undo. Patricia
From: Robert Klemme on 12 Oct 2009 17:07
On 10/10/2009 06:57 PM, Lew wrote: > 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 does have some advantages but I do not subscribe to the general "far superior". If that was the case then there would be no place for dynamic languages like Ruby, Python, Perl etc. and yet there seems to be a number of people using these languages successfully on a daily basis. And on the other hand it seems Eiffel, which does a great deal of compile time checks is not widely used if I'm not mistaken. Of course there is a difference between technical superiority and wide adoption which is often influenced by a whole number of non technical factors. But I have come to believe that in the end the advantage of static type checks is not dramatic. My 0.02EUR. Kind regards robert -- remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/ |