Walter: > Thanks for the kind words. Not everyone thinks that way > > http://www.reddit.com/r/programming/comments/gacna/bye_bye_nullpointerexceptions/c1m3r7n > > :-)
I didn't see that thread, thank you for the link. Some of your answers shown in that Reddit page were really wrong (like that "null pointer exception is reinvented"), I hope you know better now. About the notnulls topic, I have expressed my point of view some times, I think a notnull suffix syntax for pointers/object references, plus a bit of type state semantics are able to avoid most problems caused by nulls. Regarding your "dynamite general case solution", that probably Andrei too was referring with "working on a @disable property that will allow non-null types to be implemented as a library-defined type constructor." I remember some people in this newsgroup appreciating the idea, but I didn't understand it much. Null-derived bugs are indeed only one special case of bugs that are avoided in languages like Haskell, and by good typestate-based languages, so a more general solution for them all will be good. But on the other hand there is the risk of over-generalization: null-caused bugs are the most common in that class of related bugs, so maybe a solution that's focused only on null-related bugs can be better and simpler, both syntax-wise and regarding how much handy it is to use *everywhere* (because you want to use it everywhere in OOP programs and even on programs that use pointers. My suggestion was about notnullable raw pointers too). So I will wait for a more defined explan! ation of this @disable idea, to comment some more. Bye, bearophile
