4 new changes to the Dart language spec

The Dart team published version 0.08 of the Dart language spec, including 15 changes. I've detailed four of the most exciting changes below, some of which you might have seen as early proposals. Not all of these changes are implemented yet, but they show what direction the language and team is moving.

Lazily Initialization for static variables

This change was proposed in February 2012.

Previously, static class variables and top level variables had to be compile time constants. This kept initialization costs at startup low, but otherwise was constraining to the developer. With this change, static class variables and top level variables will be initialized at first access (lazily) and no longer need to constant. This is a developer friendly change that keeps initialization costs low.

Version 0.08 of the spec now reads "Static variable declarations are initialized lazily. The first time a static variable v is read, it is set to the result of evaluating its initializer."

For example, this will soon be possible:

class Awesome {
  static PonyPower ponyPower = new PonyPower();

class PonyPower {
  // NOT a const constructor
  PonyPower() {
    // feed and groom pony

  activate() {
    // summon rainbow

main() {
  var power = Awesome.ponyPower; // initializes ponyPower now

This feature is not yet implemented (as of 2012-03-25).

New equality semantics

This change was proposed in January 2012, and with version 0.08 of the spec, it finally gets added to the language.

In my opinion, equality in Dart just got a lot more simple. With the new changes, equality of the form a == b works like this:
  1. If a === b (is same instance), return true. Otherwise,
  2. If either a or b is null, return false. Otherwise,
  3. return the result of a.equals(b)
You are free to implement .equals() in your class to further define equality semantics. The rules imply you no longer need to check for === or null in your .equals() method.

This feature is not yet implemented (as of 2012-03-25).

Cascaded method invocations

This change was proposed in February 2012. Also, this particular feature should be considered less stable than the others.

Cascades allow you to chain numerous method calls to the same object, even if the API wasn't originally designed for that.

For example, consider the case of using the HTML5 Canvas API. Before the cascade feature, you would have to write the following code:

ctx.fillStyle = penColor;
ctx.arc(tx, ty, penWidth/2+2, 0, PI2, true);
ctx.moveTo(wx, wy);
ctx.strokeStyle = "black";
ctx.lineTo(tx, ty);

With cascades, this gets simplified and less redundant with:

..fillStyle = penColor
..arc(tx, ty, penWidth/2+2, 0, PI2, true)
..moveTo(wx, wy)
..strokeStyle = "black"
..lineTo(tx, ty)

The treatment for a cascade, which is object..method, is essentially like writing:

(x){x.method; return x;}(object)

In other words, "create a function, pass in some object x,  call the method on x, and return x".

Note that array and map calls also work with cascades, as a cascade can work with any method, operator, setter, or getter.

This feature is not yet implemented (as of 2012-03-25).

Removal of String + concatenation

This change we've been warning about for a while.

Having + to concatenate Strings leads to puzzlers, and we're taking advantage of building a new language by taking this opportunity to remove some of the subtle "features" that have lead to known puzzlers in the past.

Before you cry out in angst, allow me to show you how to deal with Strings, including a new feature that came in to compensate for removing +.

Remember that Dart has String interpolation, which can lead to code like this:

var name = 'Bob';
var msg = 'Hello, $name.';

Also, Dart has multi-line Strings thanks to triple quotes:

var html = """
  <td>Snake Eyes</td>
  <td>Storm Shadow</td>

For the hat trick, Dart now also has adjacent String literals:

var reallyLongLine = 'Sometimes you just need to work with really long lines '
                     'and a triple quotes multi-line string will not work. Luckily '
                     'Dart will automatically concatenate adjacent string literals '
                     'just like thing!';

Both the Dart VM and the Dart to JavaScript compiler already support adjacent string literals, so we encourage you to remove all uses of + for string concatenation, as + on String will be removed soon.


There are other changes to the Dart language spec with version 0.08, so I encourage you to browse the change log in the spec itself.

In this post, I covered lazy initialization for statics, new equality semantics, cascaded method invocations, and removal of the + operator for string concatenation.

As always, the Dart team wants you to join the discussion. Please join the mailing list or enter feature requests and bug reports to dartbug.com. A good way to get early notification of some language changes is to follow the Dart News and Updates feed.

Popular posts from this blog

  • Sponsor:  Register today for  New Game, the conference for HTML5 game developers . Learn from Mozilla, Opera, Google, Spil, Bocoup, Mandreel, Subsonic, Gamesalad, EA, Zynga, and others at this intimate and technically rich conference. Join us for two days of content from developers building HTML5 games today. Nov 1-2, 2011 in San Francisco.  Register now ! This is the second article in a Box2D series, following the Box2D Orientation article. The Box2DWeb port of Box2D contains a nice example to show off the basics of integrating physics simulations into your web app. This post will provide a walkthrough of the example, explaining the high level concepts and code. First, let's see the example in action. The code for the above is open source and available on GitHub. It was adapted from Box2DWeb's example . Animating Before we look at Box2D, it's important to understand how the above simulation is animated. You might think setInterval or setTimeout is
  • In which I port a snazzy little JavaScript audio web app to Dart , discover a bug, and high-five type annotations. Here's what I learned. [As it says in the header of this blog, I'm a seasoned Dart developer. However, I certainly don't write Dart every day (I wish!). Don't interpret this post as "Hi, I'm new to Dart". Instead, interpret this post as "I'm applying what I've been documenting."] This post analyzes two versions of the same app, both the original (JavaScript) version and the Dart version. The original version is a proxy for any small JavaScript app, there's nothing particularly special about the original version, which is why it made for a good example. This post discusses the differences between the two implementations: file organization, dependencies and modules, shims, classes, type annotations, event handling, calling multiple methods, asynchronous programming, animation, and interop with JavaScript libraries. F
  • Angular and Polymer, sitting in a DOM tree, B-i-n-d-i-n-g. First comes components, Then comes elements, Then comes the interop with the node dot bind. Angular , a super heroic MVC framework, and Polymer , polyfills and enhancements for custom elements built on top of Web Components, can live harmoniously in the same app. This post shows you how to connect Angular-controlled components to Polymer-controlled elements via data binding. And we do it all in Dart . Angular and Polymer I get asked "Should I use Angular or Polymer?" a lot. My answer is, "Yes". That is, both libraries have distinct strengths, and you can use both in the same app. Polymer excels at creating encapsulated custom elements. You can use those custom elements in any web app or web page, regardless if that app is built with Angular, Ember, etc. Angular excels at application engineering, with dependency injection, end-to-end testability, routing, and services. Here are som