> 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.
I too should have been more clear. If there was a new language with
JSR308-like capabilities, I would use those to write the collection
library. Somehow I prefer
@ReadOnly @ThreadSafe List view = list;
over
ReadOnlyThreadSafeList view = list;
The former is very readable, the latter I have to split up, extract
the type and then identify the additional guarantees. I admit though
that JSR308 is a very controversial topic to begin with, so maybe type
names such as that are a small price to pay.
> 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.
Yes, this really should return true for null, however since (right
now, in Java) null is allowed everywhere, I don't mind so much.
> 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.
I remember reading it; Reinier was explaining how nullable and non-
null are not enough ( for the interested:
http://www.zwitserloot.com/2008/10/23/non-null-in-static-languages/ ).
This is exactly why I think JSR 308 and @PolyNull are the right way to
go. I agree however: non-null and final should be the default.
> Again I should have clearer: I mean tagged unions, which is more like
> Scala's case classes if I am correct.
I'm not a big fan of case classes; I like the match-case-construct,
but that you could have with multimethods. Sadly having multimethods
in tandem with multiple inheritance creates more problems than it
solves, but being able to say "this is a multimethod" (along the line
of Howard Lovatt's PEC, just more convenient) sure would be nice.
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
-~----------~----~----~----~------~----~------~--~---
