Re:Why Dart is not the language of the future.
by ohyes on Tuesday October 11, 2011 @01:09PM
(#3099385)
> 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.
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).
Re:Why Dart is not the language of the future.
by blinks on Tuesday October 11, 2011 @01:14PM
(#3099405)
You can even go farther than that -- return true on success, and anything else on failure, and you get the semantics this person wants. If the results should be saved, that should generally be done outside the if condition anyway.
Re:Why Dart is not the language of the future.
by regularfry on Tuesday October 11, 2011 @04:47PM
(#3100231)
Returning true on success is less useful because in general it's the details of a successful result that you want to operate on. It's less common (but not by any means rare, I admit) for the "happy path" through code to be concerned with details of the error.
> 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.
Re:Why Dart is not the language of the future.
by malkia on Tuesday October 11, 2011 @03:52PM
(#3100040)
An example when a==a is when a is NaN
Re:Why Dart is not the language of the future.
by regularfry on Tuesday October 11, 2011 @04:39PM
(#3100199)
Yeah, but that's literally the only time it makes sense - when you've got a first-class "undefined" or "unknown" type - and if you're going down the path of letting user classes participate in that protocol, I suspect that allowing them to override == in a slightly funky way isn't enough.
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.