Ben Schulz wrote:
>> (...) 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.
>
You are talking about how to fix Java, not what a new language should do
;-) But I agree: creating a new API for collections seems a worthwhile
effort in the Java world. Maybe something with (fake) closures, too.
>> 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
>
The problem with Java's null is the instance of bottom in the static
type system, but outside the dynamic type system. Classic puzzler:
public boolean puzzle(String par) {
return (par instanceof String);
}
How to get a false? Pass a null. The type systems don't match.
The @Nullable style I don't really like since it (a) has the wrong
default and (b) is even more painful than using final everywhere. I
would much prefer a Nice-style '?' for optional types -- since we have
legacy code you'd also need at least the '!' for clarity. There was a
thread on that topic a while ago.
>> 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.
>
I agree. I should have been clearer.
>> join and union types
>>
>
> If with union types you mean C/C++ unions, I would respectfully
> disagree.
>
Again I should have clearer: I mean tagged unions, which is more like
Scala's case classes if I am correct.
>> 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.
I've been wondering about that, too. You could go very far and even find
yourself in the land of undecidability. I think XSD part 2 might be a
good inspiration, though.
But maybe I'm asking too much :-)
Peter
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en
-~----------~----~----~----~------~----~------~--~---
