I was going to mention that as well. Null handling in Java is not analogous to Vala's strategy, if for no other reason than there's no NPE.
It looks to me the idea of a future Vala that emphasizes code correctness is that it will catch things like this: Xyxxy? x = get_xyzzy(); int result = x.foo(); The compiler will flag that last line as problematic. I think it will, at least. I don't really know. But it seems to me that if null-checking is going to be enforced by the compiler, it's not too much to ask the language to supply good tools for doing that checking. The nullable operator is one step in that direction, but I've coded many lines where I needed something like the Elvis operator (and the associated operators suggested by Project Coin). I'll also point out that (according to the Project Coin page) the reason the null-safety operators were turned down by the Java committee was that the Checker framework was added to Java and that Groovy, the inspiration for the proposed syntax, uses dynamic typing, which makes the operators more flexible. But the first is not going to happen for Vala (I've not heard of any such framework) and the second could be made to argue against the nullable operator, which was, in fact, added to Vala. I think the Elvis operator (and its cousins) should get real consideration and not be dismissed merely because Java didn't take them. -- Jim On Tue, Jan 31, 2012 at 7:27 AM, Artem Tarasov <lomerei...@googlemail.com>wrote: > > As a starter, Java rejected that syntax. > > Yeah, but in Java at least a NullPointerException is thrown when null > dereferencing occurs. In Vala the only option to provide null-safety > is explicit checking for null after each method call in a chain. > _______________________________________________ > vala-list mailing list > vala-list@gnome.org > http://mail.gnome.org/mailman/listinfo/vala-list >
_______________________________________________ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list