News for hackers. Stuff that matters.
Re:Why Dart is not the language of the future. by darklajid on Tuesday October 11, 2011 @10:59AM (#3098810)
> This makes as much sense as 'everything' being true. You would write if (true) {...}, but I can't imagine why you would do that.

I think his real point is that there's no 'truthy', no evaluation to true. Later in the article he says that

  if (a) a.foo(); 
isn't possible because of that. A better example would've been (a != null) instead of (1 == 1), imho.

> This seems to directly contradict the first point. Which is it? It should do a dynamic type check and generate a run time exception in both cases. I don't see anything to convince me that "2" + 2 will be a concatenation... in the spec.

Not in the spec itself, right. But the current documentation seems to imply exactly what he states. See the definition of '+' here: http://www.dartlang.org/docs/api/String.html#String::String

"String +(Object other) Converts other to a string and creates a new string by concatenating this string with the converted other. "

Re:Why Dart is not the language of the future. by ohyes on Tuesday October 11, 2011 @01:12PM (#3099397)
> A better example would've been (a != null)

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.

Re:Why Dart is not the language of the future. by bad_user on Tuesday October 11, 2011 @03:46PM (#3100015)
Considering this is a new language, why allow nullable references in the first place? What you call good practice I actually consider a curse.
Re:Why Dart is not the language of the future. by ohyes on Tuesday October 11, 2011 @04:23PM (#3100146)
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.

Like I said, I'm not particularly a fan of Dart.

Re:Why Dart is not the language of the future. by rat on Wednesday October 12, 2011 @03:58AM (#3101938)
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

Re:Why Dart is not the language of the future. by dhugiaskmak on Tuesday October 11, 2011 @04:06PM (#3100092)
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.
Re:Why Dart is not the language of the future. by fpgeek on Tuesday October 11, 2011 @10:02PM (#3101181)
Re:Why Dart is not the language of the future. by uxp on Tuesday October 11, 2011 @04:12PM (#3100111)
> > "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

Re:Why Dart is not the language of the future. by darklajid on Wednesday October 12, 2011 @06:06AM (#3102255)
That's what the documentation says, imo.

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".