light weight types
in [Java Help]
|
Prev: Putting passwords in a properties file?
Next: Interview
From: John B. Matthews on 30 Sep 2009 03:00 In article <7ig1fsF319h9fU1(a)mid.individual.net>, Mike Amling <mamling(a)rmcis.com> wrote: > Surely someone somewhere must have something like this already, with > classes or interfaces for time, distance, mass, etc. JSR-275: <http://jscience.org/api/index.html> -- John B. Matthews trashgod at gmail dot com <http://sites.google.com/site/drjohnbmatthews>
From: Alessio Stalla on 30 Sep 2009 04:54 On Sep 29, 10:32 pm, Michal Kleczek <klek...(a)gmail.com> wrote: > Alessio Stalla wrote: > > On Sep 29, 9:35 pm, Michal Kleczek <klek...(a)gmail.com> wrote: > >> markspace wrote: > >> > Michal Kleczek wrote: > >> >> The ones I think are needed are changes extending the > >> >> type system so that more bugs can be eliminated statically > > >> > What sort of changes would you advocate? > > >> Hmm... It is more like a wishlist: > > >> 1. Option types > >> Whatever the name of the feature - I'd like to be able to mark a variable > >> as not null (I would actually prefer to mark variables as nullable but > >> that would not be backwards compatible). And I don't think adnotations > >> are enough. > > > I don't like this. Marking a variable as not nullable may mean two > > things (not necessarily mutually exclusive): > > > - that the variable is checked statically by the compiler to never > > ever be assigned null, and the program does not compile if the > > compiler cannot determine this. This would make the feature be not > > very useful because most of the time it's not possible to determine > > statically such a property of variables, especially when it would > > matter most, i.e. when the value comes from an outside source. > > See:http://nice.sourceforge.net/ > for a quite handy solution. > The programmer is forced to check for null when assigning a value of > nullable expression to a not null variable. Then it's the second case (runtime check), and it is even worse as the runtime check is not generated by the compiler but has to be explicitly written by the programmer. I think throwing NullPointerException is the right thing in certain cases (although often it is caused by a bug). > > Type inference would be very cool too, and it could only impact the > > compiler, while leaving the JVM and class file format completely > > untouched. > > I don't think I like this one. It think it causes (compile time) errors to > appear in wrong places (too late). I see a variable type specification as a > programmer's expectation stated explicitly. If the expectation is not met > it should be signalled by the compiler in the right place. Well I'd like type inference to be optional, not mandatory, so if you like to state your expectation about the type of the variable, or you want to use an interface even if the static type of the assigned expression is a concrete class, you'd still be able to do that. On the other hand, you could write var x = new HashMap<String, List<MyThing>>() instead of HashMap<String, List<MyThing>> x = new HashMap<String, List<MyThing>> () which imho would only make the code clearer. Alessio
From: Michal Kleczek on 30 Sep 2009 08:16 Alessio Stalla wrote: > On Sep 29, 10:32 pm, Michal Kleczek <klek...(a)gmail.com> wrote: >> Alessio Stalla wrote: >> > I don't like this. Marking a variable as not nullable may mean two >> > things (not necessarily mutually exclusive): >> >> > - that the variable is checked statically by the compiler to never >> > ever be assigned null, and the program does not compile if the >> > compiler cannot determine this. This would make the feature be not >> > very useful because most of the time it's not possible to determine >> > statically such a property of variables, especially when it would >> > matter most, i.e. when the value comes from an outside source. >> >> See:http://nice.sourceforge.net/ >> for a quite handy solution. >> The programmer is forced to check for null when assigning a value of >> nullable expression to a not null variable. > > Then it's the second case (runtime check), and it is even worse as the > runtime check is not generated by the compiler but has to be > explicitly written by the programmer. I think throwing > NullPointerException is the right thing in certain cases (although > often it is caused by a bug). I am not sure I understand your objections. What I would like to have is: //return value can be null ?String computeValue(); //here I would like the compiler to generate an error String value = computeValue(); //this is fine - notnull operator can throw NPE String value = (notnull) computeValue(); //or ?String maybeNull = computeValue(); String value = ( maybeNull == null ? "" : (notnull) maybeNull ); //this will never throw NPE int fun(String val) { return val.length(); } //but this one - can int fun(?String val) { return val.length(); } The goals is not to avoid NPEs alltogether but to have them as close to the place where the bug is as possible. > >> > Type inference would be very cool too, and it could only impact the >> > compiler, while leaving the JVM and class file format completely >> > untouched. >> >> I don't think I like this one. It think it causes (compile time) errors >> to appear in wrong places (too late). I see a variable type specification >> as a programmer's expectation stated explicitly. If the expectation is >> not met it should be signalled by the compiler in the right place. > > Well I'd like type inference to be optional, not mandatory, so if you > like to state your expectation about the type of the variable, or you > want to use an interface even if the static type of the assigned > expression is a concrete class, you'd still be able to do that. This is a matter of taste - I actually like Java because it does not give a programmer too much freedom to do bad things. > On the other hand, you could write var x = new HashMap<String, > List<MyThing>>() instead of > HashMap<String, List<MyThing>> x = new HashMap<String, List<MyThing>> > () which imho would only make the code clearer. I think it is enough to write (I don't get any compiler warnings): HashMap<String, List<MyThing>> x = new HashMap(); so there is type inference here - it is just the other way around :) -- Michal
From: Lew on 30 Sep 2009 09:07 Alessio Stalla wrote: > Well I'd like type inference to be optional, not mandatory, so if you > like to state your expectation about the type of the variable, or you > want to use an interface even if the static type of the assigned > expression is a concrete class, you'd still be able to do that. > On the other hand, you could write var x = new HashMap<String, > List<MyThing>>() instead of > HashMap<String, List<MyThing>> x = new HashMap<String, List<MyThing>> > () which imho would only make the code clearer. It does not make the code clearer, just shorter. -- Lew
From: markspace on 30 Sep 2009 10:46
Alessio Stalla wrote: > On the other hand, you could write var x = new HashMap<String, > List<MyThing>>() instead of > HashMap<String, List<MyThing>> x = new HashMap<String, List<MyThing>> > () which imho would only make the code clearer. Soon (Java 7), you'll be able to write: HashMap<String, List<MyThing>> x = new HashMap<>(); Or even: Map<String, List<MyThing>> x = new HashMap<>(); Which is more useful, imo. |