I agree that it would be better to not compare a null reference at all. A better option would be to return multiple values or have a tuple type and pattern matching.
Don't (typed) Union types work better for errors(with pattern matching)
In haskell I think a nullable type or possibly error type frequently returned from functions which can error
ie.
data Maybe a = Nothing | Just a
data Either a b = Left a | Right b
instead of
(err,result)
like in go
It was hinted in one of the other Dart threads here (or maybe on reddit) that if enough people got on the mailing list and made a good, reasoned case for it that null could still go away.
> > "String +(Object other) Converts other to a string and creates a new string by concatenating this string with the converted other. "
> This is a bad idea, now I have a gripe with dart.
I don't think this is right, and seems to be bad wording on part of the documentation. I don't have any access to an interpreter right now, besides the Google AppSpot in-browser console, but adding a String Object and a Date Object to a new variable does not alter either object or do a forced alter on the existing objects, but rather creates a new string object.
Though, I can't tell if either the date object, or the first string object in this example are altered, it appears that they aren't changed during concatenation: http://try-dart-lang.appspot.com/s/KSAX
The gripe comes from overloading the + operator, for all I can tell. That's at least the point of the author of the blog post, having + for addition and concatination, with poor type support.
The blog claims that "1" + 1 = "11" (exactly what the docs state here) and claims the same for 1 + "1".
This is a good practice, even better would be checking the type or class.
> "String +(Object other) Converts other to a string and creates a new string by concatenating this string with the converted other. "
This is a bad idea, now I have a gripe with dart.