light weight types
in [Java Help]
|
Prev: Putting passwords in a properties file?
Next: Interview
From: Joshua Cranmer on 29 Sep 2009 16:05 On 09/29/2009 03:35 PM, Michal Kleczek wrote: > 1. Option types It's already happening for Java 7--look under the heading "type annotations." > 2. First class type parameters ( "new T()" anybody? :) ) What would happen if T were an interface or abstract? Better yet, what if it were a wildcard type parameter? -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth
From: Alessio Stalla on 29 Sep 2009 16:17 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. - that every write access to the variable is checked at runtime and throws an exception if the new value is null. This would have a significant performance hit. > 2. First class type parameters ( "new T()" anybody? :) ) Absolutely, and the ability of type parameters to constrain the constructors the class must have, as IIRC .net does (given <T(Integer, String)> you can create a new T(1, "hello")) > 3. Metaclasses as described in the publication I gave link to would be useful Metaclasses are cool, but they would have a huge impact on Java and the whole JVM platform. > Just from the top of my head... Type inference would be very cool too, and it could only impact the compiler, while leaving the JVM and class file format completely untouched. Alessio
From: Michal Kleczek on 29 Sep 2009 16:18 Joshua Cranmer wrote: > On 09/29/2009 03:35 PM, Michal Kleczek wrote: >> 1. Option types > > It's already happening for Java 7--look under the heading "type > annotations." > I am not sure if it can be done with annotations. >> 2. First class type parameters ( "new T()" anybody? :) ) > > What would happen if T were an interface or abstract? Better yet, what > if it were a wildcard type parameter? > This one is also from Sun research I guess: http://www.cs.rice.edu/~eallen/papers/p079-allen.pdf -- Michal
From: Michal Kleczek on 29 Sep 2009 16:32 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. > > 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. -- Michal
From: Tom Anderson on 29 Sep 2009 16:41
On Tue, 29 Sep 2009, Michal Kleczek wrote: > Tom Anderson wrote: > >> On Mon, 28 Sep 2009, Michal Kleczek wrote: >> >>> Roedy Green wrote: >>>> Think how many times you have wondered if a variable is measured in >>>> seconds, ms, or ns. Here would be a formal way to specify and check >>>> your assumption was correct. >> >> Gosling keeps talking about adding this to java. >> >>> That is not so easy to make it right. Read for example: >>> http://research.sun.com/projects/plrg/Publications/p109-allen.pdf >> >> If you want to be able to have arbitrary units which can be checked at >> compile-time, sure, you need to add difficult stuff to the language. If >> you can satisfy yourself with a fixed set of units, or runtime-only >> checking, you can do it in java now. > > Fixed set of units is problematic because it is... fixed :) > Runtime-only checking is actually no checking at all (who cares if a bug > manifests itself in an IllegalArgumentException or otherwise?) Because that's going to be a lot more obvious during testing than a value being silently wrong. tom -- drink beer and forget about gods. -- derslangerman |