Wednesday, May 16, 2012

Extract local variable refactoring now in Dart Editor

Posted by Devon Carew



New Dart Editor build is now available. Highlights from build 7696 include:
  • Extract local variable refactoring!
  • Search and search box fixes
  • Ignore . (hidden) directories for search results
  • Update #import, #source and #resource references in Dart source during resource rename in Files view
  • General fixes to the analysis server
  • And in non-editor news: the dart:dom library has been throughly deprecated
Read the full change log or start downloading the Dart Editor from the Editor tutorial.

Thanks for trying Dart!

Notes from 5/14 Dart language meeting

Posted by Bob Nystrom


Once a week, Lars, Gilad, and Kasper meet to discuss the design of the language. For your delight and edification, here are my notes from this week's meeting:

var and Dynamic

We see people using Dynamic as a type argument even when they don't have to. Also see people trying to use var as a type argument. Gilad said there are very few cases where you actually do need to use Dynamic.

The source of the confusion is that var is used in a place (local variable declaration) where you can also use a type to declare a variable, so it makes people think var is itself a type.

He proposed always requiring var to declare variables to clarify that:

  var int foo = 123;

but doesn't think it will be liked.

Alternately, we could follow users' intuition and allow var to be used like a type:

  var map = new Map<int, var>();

Gilad is worried allowing var anywhere a type can appear may have some unpleasant corner cases we aren't thinking of. He likes the current behavior because he knows it is non-problematic.

No decision was reached.

I asked if when a user declares a variable with var are is the intent they are stating that they don't care what the variable's type is, or that they do care and want it to be dynamic? Gilad said from the language's point of view, it doesn't matter because there is no difference.

Re-export

Agreed to have an "export" parameter in #import directives. So to re-export, you do:

  #import('somelib.dart', export: true);

If you want to use a library internally but only re-export a subset of its names, you would do:

  #import('somelib.dart');
  #import('somelib.dart', show: ['foo', 'bar'], export: true);

One consideration is how this works with prefixes. If you re-export something you imported with a prefix, does the prefix compound?

The current answer to keep the semantics restricted is "no". Prefixes are for using a name internally, and do not affect how it gets exported.

Cast syntax

Our hangout flaked out and Gilad dropped off for a few minutes. In that interim, we briefly discussed an explicit cast syntax.

Kasper pointed out that if you want to support an optional second type system that doesn't allow implicit downcasts, you'll need some kind of cast syntax. Lars says "as" is probably a good idea.

Statics on interfaces

Lars does not like code appearing in interfaces. Kasper says default classes are confusing for people, and that in large interfaces, people don't see that the constructors are there.

We talked briefly about constructors in interfaces just working like factory constructors so that you wouldn't need "default" to do the delegation.

Lars had to leave at this point. I don't think there was a firm decision, but it seems like we do not intend to support static methods defined directly in interfaces but may support them by delegating to the default class.

Directives

Kasper mentioned that we may want to refresh the directive syntax at some point. Users don't seem to like it. Gilad favors dedicated syntax for imports.

Cheers!

Tuesday, May 15, 2012

5 items the Dart team has on their radar

Posted by Seth Ladd

Hello Dartisans,

Some of you have asked what the bigger picture is with what we’re working on. The Dart team has the following items on their radar. There is no particular order or priority implied, nor is this exhaustive, but these are some of the features we are either working on or intend to work on.

Across all components we are working improving performance and stability.


  • Dart language and libraries
    • Language see http://goo.gl/2Z9ZY (Area-Language, Milestone-M1)
    • dart:html: parity with the deprecated dart:dom, IndexedDB
    • dart:io: HTTPS, improved HTTP support, optimize performance
    • Package manager: discover, install, upgrade, version, and publish.
    • Date refactoring
    • Continued work on Future and Isolates API
  • Dart Editor
    • background analysis (which will provide a significant speedup)
    • debugging support (browser and VM)
    • simple refactoring support (various rename options to start)
    • search improvements (like text search in libraries)
  • Dart VM
    • debugging standalone and server programs (from command line and from Editor).
    • conformance with the language spec (in particular synchronize with dart2js when implementing new features)
    • implementation of mirror based reflection
    • improved handling of GC
    • rollout of optimizations to the new compiler pipeline
  • Dartium and Dart + Dev Tools
    • dev tools debugger to understand Dart scripts
  • Dart compiler to JavaScript
    • dart2js to replace frog
    • conformance with the language spec
    • improve size and performance of generated JS code

As always, thanks for trying Dart! Please join the Dart mailing list for discussions, and check out Stack Overflow for how-to questions. Please use http://dartbug.com to file bugs and issues.

Saturday, May 12, 2012

New Dart Lang Spec tweaks switch statement, abstract methods, and more

Posted by Seth Ladd


We just published version 0.09 of the Dart Language Spec.

Changes include:

  • Abstract methods may specify default values.
  • Interface methods may specify default values.
  • The ~/ operator can apply to doubles.
  • Refined rules regarding abstract class instantiation, allowing factories to be used.
  • switch statement specification revised.
  • throw may not throw null.
  • Imports introduce a scope separate from the library scope. Multiple libraries may share prefix.
  • Recursive typedefs disallowed.

The switch statement now requires either all the expressions in the cases to evaluate to constant integers or they all evaluate to constant strings. Also, a warning can be generated if you omit the break statement in a case.

As always, the Dart mailing list is standing by to answer your questions, and dartbug.com is a good way to file bugs and feature requests.

Friday, May 11, 2012

New Dart Editor release improves refactoring

Posted by Devon Carew



New Dart Editor build is now available. Highlights from build 7552 include:
  • Improvements to rename refactorings: import prefixes, local functions, getters and setters. Warn when renamed type or member becomes private.
  • Editor compiles both frog and dart2js output in parallel; in a few weeks we'll switch over to solely using dart2js.
  • Fixed external files to open as read-only.
  • Landed sdk text search functionality.
  • Improved text file type filtering (no .dart.js or config dir content).
You can read the full change log or download the Dart Editor from the tutorial.

Dart I/O library now uses Future for async

Posted by Mads Ager


We heard your feedback for an easier-to-use I/O library, so we just landed a change to make dart:io use futures for single-shot async methods.

For example, where you used to write:

var f = new File('myfile');
f.onError = (e) => print(e);
f.exists((b) => print('exists: $b'));


you now write:

var f = new File('myfile');
var existsFuture = f.exists();
existsFuture.then((b) => print('exists: $b'));
existsFuture.handleException((e) {
 print(e);
 return true;
});


This change has multiple advantages:
  • It is more consistent with the rest of the Dart APIs to use Futures.
  • File and Directory objects are now immutable.
  • Error handling can be done locally per operation instead of having a global error handler and you get the benefit of the error handling mechanisms built into futures.
The details are in the code reviewWe have also updated the Dart I/O API docs.


As always, please share your feedback with us in the Dart mailing list. Thanks for trying Dart!

Thursday, May 10, 2012

Learn about Dart in Berlin on May 24

Posted by Seth Ladd

Join Dart engineers in Berlin for a night of Dart on May 24th. The Berlin GTUG is hosting an Introduction to Dart, in partnership with Berlin JS and JUG BB.

From the original announcement:

The two fold event on Thursday, 24th of May, will take place at co-working space AHOY!Berlin in Charlottenburg near Stuttgarter Platz.
The first part of the event offers some hands-on Dart experience (from setting up the SDK, IDE, to some “hello world!” accomplishment) and will take place from 4pm to 6pm. Please register at meetup for the first part of the event.  All participants are expected and required to bring their own laptops and power cords. AHOY!Berlin will provide WiFi and 'some' power outlets.
The second part will be a presentation about Dart with Q&A (7pm to 9pm) followed by a get together in the Ahoy Lounge where we can continue with a laid-back general discussion about Dart. Please register at meetup for the second part of the event.

Thanks to all the organizers for this joint event to learn about Dart. This is a great chance to meet some of the Dart engineers, ask questions, and join in the conversation. Hope to see you there!