> (...) while I personally believe the collections API is a pile > of dung from a conceptual point of view, it is an existing standard with > decent implementations. (...)
I agree, but the collections library I would like to have would comprise so many interfaces that most developers would be repelled. I think forcing JSR 308 (or something like it) on the masses and then creating a collections API on top is the only viable way of getting type-system-enforced immutable, read-only, mutable, fixed-size, synchronized,... collections. > Long story, shorter conclusion: what I would be looking for is a > language that looks very Javaish and has strong static typing. Yes! > at least explicit nullability Again, JSR 308 would do for me. Also I would not mind having "null" renamed to "nothing". The name is much more fitting for the bottom type in an OO language. Having access to that bottom type would be neat too: "public <E extends IOException> void method(...) throws E" would be so much more useful if I could call "obj.<Nothing>method (...)". The Java bug report comes with a longer, more compelling example: http://bugs.sun.com/view_bug.do?bug_id=5060259 > and closures, No argument here. > no broken arrays, I would drop arrays! (At least in the way that scala dropped them.) Just thinking about the problems arrays cause with the evolution of Java today I don't see any reason for attaching that anchor to a new language. > join and union types If with union types you mean C/C++ unions, I would respectfully disagree. > maybe even simple constraints such as Integer[0..5] I thought about that a couple weeks ago, but next people will want to express "an integer divisible by 4" or a string that matches "\A(\d+)x (\d+)\z". Wouldn't it be awesome if you could -- as part of your library -- code up subtype-relations? So the language would come with the value type javasjava.lang.Rat (a rational number). Then you define relations over /, <, <=, > and >=, so you could have a value type javasjava.lang.Int; each would be a Rat but divisible by 1 and a Nat would be an Int >= 0. Expressing such types would have to happen with something more akin to class definitions and not inline, you'd have to write up a type "ZeroToFive" or so. Obviously you won't be able to statically check all assignments (not soundly anyways), but even if you only gave people the "Integer [0...5]" there would still be casts and runtime checks. Ah well... this would probably be overshooting "Java's Java", forget I said anything. With kind regards Ben --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
