For the latest Dart news, visit our new blog at https://medium.com/dartlang .
The incomporable Bob Nystrom fills us in on the language design discussions taking place amongst Dart engineers. Here are his notes from the June 10th language meeting:
Here's my notes from this week's (short) meeting:
Name collisions with dart: imports
[A customer recently ran into an issue where a new type appeared in dart:html whose name collided with a name they were importing from elsewhere. This broke their app.]
Gilad brought up this issue. Pete's suggestion is if there's a collision between a "dart:" import and another library, the other library wins. That way, we can add stuff to "dart:" libraries without breaking people. I explained some more details here.
Lars asked if there are any negative consequences from that suggestion and when it needs to be fixed. Kasper suggested we start making it a warning [instead of an error?] now.
Ivan asked how JS handles this. Kasper said DOM names are usually higher up on the prototype chain so you get similar shadowing behavior there to what we're suggesting for Dart now.
Type guards
Folks in Aarhus had a discussion about type guards. When you do "if (x is Foo)" in the then branch can you statically tell x is of type Foo? The conclusion they came to is that if locals aren't final, the rules are so complicated it's not worth doing. With mutable locals, you get lots of problems with closures that assign to that local.
For finals, though, they are fine with inferring the type here as long as it doesn't make the rules too weird.
I asked about parameters which are non-final by default. Kasper says you can mark those final.
Cheers!