Wednesday, January 30, 2013

Breaking Change: Iterable.mappedBy is now Iterable.map, List.skip/take return Iterables

mappedBy(), we hardly knew ye!! Florian Loitsch tells us the reason for the name change to map() 

We are reverting the name-change to 'map'. I got a lot of feedback, and the name is clearly not working for most of you. We are therefore reverting back to "map".

In order to avoid mistakes we will also make the return-type (and dynamic type) of List.map be an Iterable, and not a List. This will, hopefully, make it more clear that the result is a lazy wrapper instead of an eager evaluation.

For consistency we changed the return-type of List.skip and List.take to be an Iterable too.

We are going to keep the mappedBy method in the implementation (next to "map") for several weeks, so you have the time to migrate. The List.skip/take methods will furthermore continue to return Lists (even though their return type is "Iterable").

When we finish the transition "mappedBy" will go away, and skip/take will return Iterables (dynamic type) and not Lists anymore.

A patch for this change has already been uploaded, and will be committed soon (probably tomorrow):
https://chromiumcodereview.appspot.com/12086062/.

Since we changed the name in the Iterable, we also changed it in the Stream class. So Stream.mappedBy is now Stream.map.

As always, we invite you to join our Dart mailing list, ask questions on Stack Overflow, or file feature requests on dartbug.com

New Iterable API Can Filter, Transform, and More

Dart engineer Florian Loitsch has published a new article on Dart M3's Iterable interface. Available today as a preview, you can use Iterable to filter, transform, chain, and more. Many of the collection methods have moved up to Iterable.

Florian writes:

Iterable was extended with many Iterable-returning methods. These are lazy methods in that they only wrap the original instance. They do not immediately perform any work. Instead, it is the iterators of the wrapping objects that do the actual work. As a consequence it is possible to modify the original Iterable (adding new elements, or deleting them) and the wrapping iterable will see the changes. (Of course, it is still not allowed to change an iterable while an iteration is in progress.)
New methods include methods to skip the first elements (skip() and skipWhile()), or to ignore remaining elements (take() and takeWhile()). We furthermore moved the Collection methods map() and filter() to Iterable and renamed filter() to where().

Dart Editor can help you upgrade with the Clean Up tool. It can detect usages of the old API, and suggest and apply the new syntax.

After you read the article, we look forward to your feedback on the Dart mailing list. Thanks for using Dart!

Monday, January 28, 2013

New Dart Editor Build With Expanded Exception Debugging and Autocompletion in Import Statements


Dart Editor has new build. Eric Clayberg fills us in on the details:
A new Dart Editor build is available at www.dartlang.org/editorChanges include:
  • Added a new launch configuration for Chrome packaged apps.
  • Add the ability to specify the break-on-exceptions behavior in the debugger (break on all exceptions, uncaught, or no breaking).
  • The editor now supports autocompletion in import statements!
  • Improved labeling on empty Dart search results
  • More navigation menu enhancements
  • Fix for resolving package: imports in dart scripts in HTML files
  • Various analysis and editor fixes
Breaking Change List:
  • Window.requestLayoutFrame is being renamed to window.setImmediate- it's functionally equivalent. The API is essentially a microtask API for executing callbacks after the current stack has unwound but before the next event and the rename is intended to be clearer about that. We've also improved the underlying behavior on IE (to use window.setImmediate) which will bring that more in-line with the WebKit behavior.
  • Element.getComputedStyle will no longer be asynchronous- it now returns the style rather than a Future. Be warned that this can invoke a browser layout operation- it's not a cheap API to use performance-wise.
  • Element.computedStyle is being removed. Use Element.getComputedStyle instead. Since this API had side-effects (invoking a browser re-layout), it was not appropriate as a getter.
  • Uri.fromString() renamed to Uri.parse()
Andas always,view the changelog for the full list of changes, and to get started with the Editor see our tutorial.
We invite you to join our Dart mailing list, ask questions on Stack Overflow, or file feature requests on dartbug.com.

Tuesday, January 22, 2013

Important New Dart Editor Build with Support for New Dart Libraries


Dart Editor has a very significant new build that integrates support for many of the new v2 libraries. Eric Clayberg fills us in on the details and warns that this build is likely to break existing code:
A new Dart Editor build is available at www.dartlang.org/editorChanges include:
  • Mixin support in code completion and refactoring.
  • Revised navigation menu items on editor context menu.
    • Items only appear when applicable
    • New “Find all” item to search for all declarations of a method
  • In the command-line debugger, selecting a running isolate will display all the libraries for that isolate, and all the top-level variables for those libraries. 
  • For both debuggers, break-on-exceptions is now enabled by default (Issue 4765).
  • Added a new wizard for creating Chrome apps.
    Thanks to Adam Singer for the template for this wizard!
  • Added a new wizard for creating a web-ui application.
    Thanks to Chris Buckett for the CL to make this happen!
  • Editor samples and wizards updated to use the new location of dart.js (the browser pub package).
  • Fixed deletion of folders/files on Windows so that just the links are deleted and not the actual files on disk (Issue 5583).
  • Bug fixes and cleanup to the plugins distributions, especially related to launching applications.
  • Various analysis, editor, theming and refactoring fixes
Breaking Change List:
Andas always,view the changelog for the full list of changes, and to get started with the Editor see our tutorial.

Wednesday, January 16, 2013

Breaking Change: the Hashable Class to be Removed

The Hashable class is being removed. William Hesse tells us why

Since everything is hashable, there is no need for a Hashable class. 
We've kept a class with that name alive, so that code using it wouldn't break, but now it's time to let it go.

As always, we invite you to join our Dart mailing list, ask questions on Stack Overflow, or file feature requests on dartbug.com

Breaking Change in dart:io Path() Class Makes it Easier to Deal with Windows Paths


Some changes are coming to the dart.io Path class constructor that will help make Windows paths platform agnostic. William Hesse gives us the details

I have finally changed the new Path(String path) constructor to automatically convert Windows paths into platform-independent paths, the way that new Path.fromNative(String path) does now.  I found no cases where code needed to create a path without doing this conversion on the Windows platform, so we thought we should make it the default.  It is fine if this conversion is done more than once to a path, since it has no effect the second time.

The reverse of this conversion is done by the toNativePath() method of Path, which returns a string which follows the conventions of the platform.  On Windows, slashes are changed back to backslashes, an initial slash is removed from a drive letter, if present, and a network share starting with two backslashes has them restored.

The previous functionality of new Path() has been renamed to new Path.raw(String path), but we are considering removing it, since it seems to be more confusing than useful.  If anyone knows of a use case for it, please chime in.

.  Note that these are the bleeding_edge API docs, and not the slightly more stable Latest API docs at http://api.dartlang.org/docs/releases/latest/

As always, we invite you to join our Dart mailing list, ask questions on Stack Overflow, or file feature requests on dartbug.com

First Look at new Dart Libraries

The Dart libraries are implementing a common model for processing a stream of events, and you can try the new libraries now with a preview release of Dart Editor. Developers consistently told us they wanted a more unified method for dealing with asynchronous events. The new Streams API from the dart:async library delivers on the vision of a builtin way to listen for, transform, and emit a sequence of events.

Beautiful streams.

There are numerous changes in the new Dart libraries, above and beyond just Streams. Here is a look at what's new, with some tips for migration. Note: this list is not comprehensive. You can explore the API docs to learn more about these new libraries.

Core library

  • Iterable interface is changed. Now uses "bool moveNext()" and "E get current" to advance and read the current value.
  • Iterable interface is greatly extended.
    • Collection methods moved to Iterable, e.g. any and contains.
    • ‘map’ has been renamed to ‘mappedBy’. The result is lazy.
    • ‘filter’ has been renamed to ‘where’. The result is lazy.
    • Many new operations, and some old operations, now work on all Iterables.
    • Iterable transforming methods (those returning a new Iterable) are lazy - that is, they don't create a new collection immediately.
    • Added Iterable.toList() and Iterable.toSet(). This allows easy porting from old code: foo.map(...) -> foo.mappedBy(...).toList()
  • Added optional function argument to int/double.parse which is called in case of a parsing error. Default behavior is to throw FormatException as before.
  • Added optional arguments to int.parse: “radix”. Example: int.parse(“ff”, radix: 16) -> 255.
  • Changed int.~/ to always return an int value.
  • Added String.replaceAllMapped that takes a function to compute the replacement for each match.
  • Removed Sequence class.
  • The generic List constructor is not fixed length anymore if an argument is given. The list’s size can still be changed afterwards.
  • There are two new named List constructors: List.fixedLength(length, {fill}) and List.filled(len, fill).
  • Strings.join now takes an iterable, but Strings will be removed. Iterable now has a join. Also, Arrays will be removed.
  • map.keys and map.values no longer allocate a copy, so avoid modifying the data structure while iterating. Instead, create the copy by using "for (var key in map.keys.toList())"


Collections


  • Added separate collection library, "dart:collection" for implementations and collections beyond plain Map, Set, and List.


Async


  • Library "dart:async" added.
  • Future and Completer moved to async library.
  • Timer moved to async library.
  • Future interface greatly changed. Most importantly:
    • "chain" and “transform” combined into "then" by checking whether the return value of the handler is a Future.
    • Future is now purely asynchronous - you can't read a value or exception directly from the future, but must register an event handler to receive it at a later time.
    • To fix existing uses of Future: Change "chain" to "then". Always register a "then" or "catchError" handler immediately when you receive a future, or you might not catch an error in time.
  • Added Stream: an asynchronous event source. Single or multiple listeners, produces sequences of both value events and errors.
  • As an asynchronous version of Iterable, Stream has async versions of the transforming methods of Iterable.
  • New AsyncError is now wrapping all errors propagated to async event handlers, both on Future and on Stream.



JSON


  • Library interface changed: No JSON class, methods renamed.
  • Added optional "reviver" argument to parse.
  • Removed length method.



HTML


  • For more information, see our mailing list post.
  • on.click.add is now onClick.listen (streamified)

We invite you try your code with the new libraries, join the discussion on the Dart mailing list, and file issues and bugs at the Dart Issue Tracker.

Photo Credit: ecstaticist (cc)

Tuesday, January 15, 2013

New DOM Event Streams API makes it Easier to Listen to and Capture Events

A new API is on the way for dealing with DOM events in Dart. Google engineer Peter Bois gives us the details:
One of our goals for exposing DOM events in Dart is to have them follow the 'best practices' for events- particularly events which are exposed in places such as your application data model.

The current plan is that DOM events would be exposed as:
class Element {
  static const HtmlStreamProvider<MouseEvent> clickEvent = 
    const HtmlStreamProvider<MouseEvent>('click');

  Stream<MouseEvent> get onClick => clickEvent.forTarget(this);
}

The HtmlStreamProvider class is:
class HtmlStreamProvider<T extends Event> {
  const HtmlStreamProvider(String eventType);
  Stream<T> forTarget(EventTarget e, {bool useCapture: false})

}

There's basically two parts- 
  1. The static declaration of the event as an HtmlStreamProvider which provides a Stream for a DOM event on a specific target. This is only really used for bubbling DOM events.
  2. A Stream<> getter on the object instance to allow easy access to the event stream.
NOTE: we will not remove the old APIs until the new APIs have been in & baked for a while.

Examples of old vs new syntax:

Listening to an event
Old:
element.on.click.add((e) {
});
New:
element.onClick.listen((e) {
});

Capturing an event
Old:
element.on.click.add((e) {  
}, true);
New:
Element.clickEvent.forTarget(element, useCapture:true).listen((e) {
});

Listening to a bubbled event
Old (not really supported):
document.body.$dom_addEventListener('canPlay', (e) {}, false);
New:
MediaElement.canPlayEvent.forTarget(document.body).listen((e) {
});


QUESTIONS:
  1. Are you planning on exposing all model events as Streams? By this I mean something like backbone.js-style events. Our goal for DOM events is to be consistent with the dominant data event model.
  2. Any opinions on naming? Currently the events are exposed as onEventName, but it's often common to use this naming style for virtual methods. Using just eventName has a number of conflicts with members. We aren't entirely thrilled with onEventName.
If you're interested in taking a peek, the CL with the changes is at:

As always, we invite you to join our Dart mailing list, ask questions on Stack Overflow, or file feature requests on dartbug.com.

Monday, January 14, 2013

BIG BREAKING CHANGE: dart.js Bootstrap File is Moving to Pub



dart.js file is moving to Pub and can be found in the new browser package. The familiar link to dart.js from your html files,
should be replaced by declaring a dependency to this package, or by hosting a local fileThis is a far reaching change that will impact all browser based Dart applications; Dartisans are urged to follow the advice provided by Vijay Menon

FYI: We are moving the bootstrap file dart.js to pub.  Please update any links to dart.js from your html files accordingly.  

We will delete the old copy of dart.js in our repository in a couple weeks.

The dart.js file is used in Dart browser apps to check for native Dart support and either (a) bootstrap Dartium or (b) load compiled JS instead.  Previously, we've recommended that you add a script tag pointing the version of dart.js in our repository.  This doesn't work offline and also results in slower startup (see dartbug.com/6723).

Instead, we now recommend that you install dart.js via the following steps:

1. Add the following to your pubspec.yaml:
  dependencies:
    browser: any

2. Run pub install.

3. Use a relative script tag in your html to the installed version:
<script src="packages/browser/dart.js"></script>
If you do not wish to use pub, you may host a copy of this file locally instead.  In this case, you will need to update it yourself as necessary.  We reserve the right to move this file in the repository, so we no longer recommend linking to it directly.
As always, we invite you to join our Dart mailing list, ask questions on Stack Overflow, or file feature requests on dartbug.com.

Friday, January 11, 2013

Notes from January 7 language meeting

Dart engineer Bob Nystrom has posted the notes from the January 7th language design meeting. He writes:

Here's my notes from this week's meeting:

call() versus operator()

Gilad brought up the perennial discussion of how classes that emulate functions should define that operation: as a method named call() or using an operator syntax.

Lars: What are problems with making it an operator?
Gilad: At this point I think we could. It's an incompatible change, but not a big deal.

Configuration-specific code

Gilad has a rough proposal he's working on for this.

Method cascade grammar

[Bob: I think the Dart implementations and spec are out of sync regarding how they handle precedence of method cascades in particular with respect to the ternary operator.]

Gilad: The grammar for cascades makes sense from perspective of someone looking at the grammar, but not as much for someone trying to program using them.

Kasper: There are a couple of corners of the grammar that are confusing and there have been bugs filed. Maybe we should take a look at moving some things around.

Lazy loading libraries

Lars: Something to move up on the list is lazy loading. Aarhus has started working on this.

Kasper: Should be able to compile into multiple specific files that are loaded somehow on demand and can be stitched together.

Gilad: This and configuration-specific code are somehow related.

Cheers!

As always, we invite you to join our Dart mailing list, ask questions on Stack Overflow, or file feature requests on dartbug.com.

Tuesday, January 8, 2013

New Dart Editor Build with Expanded Windows and Chrome Apps Support



Dart Editor has new build. Eric Clayberg  fills us in on the details:
A new Dart Editor build is available at www.dartlang.org/editorChanges include:
  • Windows love!
    • You can now debug command-line applications from the editor! This was a long-awaited feature.
    • The command-line dart_analyzer tool is now available in the Windows SDK (dart-sdk/bin/dart_analyzer.bat).
    • Various Windows bug fixes and UX cleanup.
  • Several changes in support of building Chrome Apps:
    • Add a setting to allow the user to pass custom flags to dart2js (like --disallow-unsafe-eval). To configure this, right-click on a project and choose 'Properties'.
    • Added a manifest.json editor.
  • Improved support for Dart code in html files
    • Syntax highlighting
    • Analysis for inline scripts.
  • Package version information is now shown in the Files View
  • The Problems view can now optionally just show problems for the currently selected project.
  • Improved css and yaml editors
  • Filter log entries during test execution
  • Various analysis, editor, theming and refactoring fixes
And as always,view the changelog for the full list of changes, and to get started with the Editor see our tutorial.

We invite you to join our Dart mailing list, ask questions on Stack Overflow, or file feature requests on dartbug.com.

Monday, January 7, 2013

Dart Lands First Set of Library v2 Changes

The first big set of "Dart library v2" changes landed in the bleeding_edge branch today, which means it's time to investigate changes required to your code and pub packages. Further details about the changes, along with tips for updating, are forthcoming. For now, here's what you, our intrepid Dart developers, need to know.



The biggest changes are to async and collections

Everyone's first question: so, what's new? Until we publish a more comprehensive list of changes, here's a short, incomplete list to wet your whistle:

  • The new dart:async library now contains Future, Timer, and Streams.
  • The Future class changed quite a bit. For example, chain and transform are now simply then.
  • The new dart:collection library has more functionality beyond the basics found in dart:core.
  • The Iterator class changed, with new methods moveNext() and current. Many new operations, and some old ones, work with Iterable.
  • List gets two new named constructors: List.fixedLength(length, {fill}) and List.filled(len, fill).
  • Lots more...

The bleeding_edge docs are available for further exploration. To be clear, there are more changes than what is listed above. A more detailed post is on its way.

The M2 build is stable for 2-3 weeks

If you use the M2 build (essentially the latest Editor build, revision 0.2.9 or 0.2.10), you are insulated from these changes for now. We do not intend to push the library changes to the Editor builds for at least two weeks. This gives us enough time to update internal and external packages pushing out a new build.

Docs for M2 libraries are now available

You can now access API docs that match the shipping version of the SDK and Editor. The api.dartlang.org site now redirects to api.dartlang.org/docs/releases/latest/ which tracks the version of the SDK that ships in the editor's (mostly) weekly releases. The bleeding_edge docs are still available, if you want to see what's coming up.


Lock your pubspec.yaml file, or avoid updates, for 2-3 weeks

If you use pub to integrate third-party libraries, we advise you to do one of the following to minimize risk of a breaking change:

  • Avoid running pub update until after you get a new version of the stable Editor and SDK. This will probably be 2-3 weeks from now.
  • Manually lock the versions of your dependencies, by updating your pubspec.yaml and using specific version numbers instead of the any keyword.

The bleeding_edge branch is a moving target

The bleeding_edge branch, which is where all these library changes are getting merged, is going to take a few days to settle down. If you're experimenting with Dart's SVN repository or otherwise working with bleeding_edge, be warned. We're not quite done with the merge, and we have tests to fix.

Pub authors: Learn about the new changes

If you are the author of one or more pub packages, now is a great time to learn about these changes. Wait until our build bots turn green, and then you can download a bleeding_edge build to try it out. Meanwhile, you can view the bleeding_edge docs. Fear not, you can install the bleeding_edge version alongside your M2 build.

Thank you for your patience and feedback


We know these changes cause work for all of you, our developers. Our aim is to respond to feedback now, and make these changes as quickly as we can, so we can get to 1.0 and a more stable Dart. Thank you for your patience. We look forward to your feedback on the mailing list, and your bug reports and feature requests at dartbug.com.


(Image courtesy of http://www.flickr.com/photos/vblibrary/4419780791/)