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();
> 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. "
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.
Like I said, I'm not particularly a fan of Dart.
ie. data Maybe a = Nothing | Just a data Either a b = Left a | Right b instead of (err,result) like in go
http://qconlondon.com/london-2009/presentation/Null+Referenc...
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".
As I understand it, it's not that you might write if(1){} literally. It's that you might write a method to return <something> on success or null on failure, and ordinarily that would be reusable in a conditional. In Dart, it's not - unless you're careful. This is not the sort of thing we have grown up thinking that we need to be careful about.
Combined with the author's example of a==a potentially evaluating to either false or true depending on the class in a really unexpected way, I'm just seeing potential for confusion and I can't see any immediate reason why they would have thought that this would be a good idea. Yes, the spec mentions JS's problem with an autoboxed false, but they've just moved that problem around, they haven't solved it.
Doing this is like writing a pun into your code. Check the type of it, or check if it is equal to null (or if it is not equal to null).
> If the results should be saved, that should generally be done outside the if condition anyway.
That's as may be. This is one of those areas where the language is guiding you towards a specific code pattern rather than explicitly preventing something, and I just don't think in this case the guidance is helpful or warranted. I think it's a side-effect of a workaround for a bug in the compilation target, and that's not a good thing to expose at the language spec level.
> You would write if (true) {...}, but I can't imagine why you would do that.
>Ok. This is a good thing. Auto conversion is bad.
One of the things I really dislike about developing in Ruby is that I can't do
value = 5 "The value is " + 5
I get bitten by this at least 10 times a day while developing, usually either when dumping to the log, or writing into html. I can fix the problem really quickly now, but every time I get an error:
"r" + 5 "TypeError: can't convert Fixnum into String"
I think, yes, yes you can easily convert a Fixnum into a String.
"r" + 5.to_s
It just means I have to sprinkle .to_s everywhere in my code. Ridiculous!
value = 5 "The value is " + 5
edit: what does "say" mean in the reply below? print? evaluate? and does "later" mean in another statement? or replacing what was before?
value = 5
"The value is " + 5
If you really want that value in your string, why not use "The value is #{value}"
If one really wanted that kind of behavior (and not getting errors when trying to add strings and number) you could make it so:
class String
def +(o)
warn "You are adding a #{o.class} to a string." unless o.is_a? String
"#{self}#{o}"
end
end
Whether this leads to other issues is left as an exercise for the reader and whomever ends up maintaining the reader's code.
"r#{5}" "I have #{me.num_of_children}\n" "I have " + str(me.num_of_sons) + "and " + str(me.num_of_daughters) +"\n"
> Dart programs may be statically checked. The static checker will report some violations of the type rules, but such violations do not abort compilation or preclude execution.
> In other words the "static checker" is a lint-type development aid, not a language feature.
My reading is that the language is optionally typed (similar to SBCL). The type checker will warn you when you have a type declaration that appears to be incorrect, and will optimized based on these declarations, but will not keep you from running code that violates a type-check. This is a remarkably good solution for dynamic languages.
> Here's a strange thing: the one and only true value is the boolean literal boolean true. Everything else is false. That means that code in if (1) { ... } will never execute, because 1 is a number, not a boolean, and there is no implicit conversion to boolean. You'll need to write if (1==1) instead.
This makes as much sense as 'everything' being true. You would write if (true) {...}, but I can't imagine why you would do that.
> There is no implicit type conversion between numeric, string or boolean types.
Ok. This is a good thing. Auto conversion is bad.
> The distinction between string and numbers allows to re-use the addition operator + both for addition and concatenation. However, without strong typing, this will almost certainly prove to be a bad idea. From the specs, it looks like "2" + 2 will be a concatenation, and 2 + "2" a run-time exception (in the absence of implicit conversion from string to number), but experience infirms this: string concatenation happens in both cases (although with a warning in the second one).
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.
>Thus, isolates are a heavyweight thread control model very much like Perl 5's ithreads. That means that they are good for data isolation, but heavy to use and hungry in memory, because spawning a new isolate will imply cloning all the objects and data structures of the running libraries.
There is absolutely nothing that implies this. There is a tiny section in the spec about isolates. They could easily be lightweight like Erlang processes.