[Intl] Cleanup some code

pkg/intl/lib/date_format.dart

Index: pkg/intl/lib/date_format.dart
diff --git a/pkg/intl/lib/date_format.dart b/pkg/intl/lib/date_format.dart
index 0a53f486fd90329877f9f3ea04f4be15d037860e..0f2e9fb593198cb2360cab950407e744a0566113 100644
--- a/pkg/intl/lib/date_format.dart
+++ b/pkg/intl/lib/date_format.dart
@@ -237,18 +237,14 @@ class DateFormat {
    * something has happened or how long in the future something will happen
    * given a [reference] DateTime relative to the current time.
    */
-  String formatDuration(DateTime reference) {
-    return '';
-  }
+  String formatDuration(DateTime reference) => '';
 
   /**
    * Formats a string indicating how long ago (negative [duration]) or how far
    * in the future (positive [duration]) some time is with respect to a
    * reference [date].
    */
-  String formatDurationFrom(Duration duration, DateTime date) {
-    return '';
-  }
+  String formatDurationFrom(Duration duration, DateTime date) => '';
 
   /**
    * Given user input, attempt to parse the [inputString] into the anticipated
@@ -259,10 +255,9 @@ class DateFormat {
     // TODO(alanknight): The Closure code refers to special parsing of numeric
     // values with no delimiters, which we currently don't do. Should we?
     var dateFields = new _DateBuilder();
-    if (utc) dateFields.utc=true;
+    if (utc)dateFields.utc = true;

[Alan Knight, 2014/01/28 01:33:46]

Shouldn't there be a space between the end of the condition and the statement?

[vicb, 2014/01/28 07:52:45]

fixed

     var stream = new _Stream(inputString);
-    _formatFields.forEach(
-        (each) => each.parse(stream, dateFields));
+    _formatFields.forEach((_) => _.parse(stream, dateFields));

[Alan Knight, 2014/01/28 01:33:46]

I normally treat _ as meaning "a parameter that's never used so it doesn't need
a name". Naming it that way and then using it seems wrong.

[vicb, 2014/01/28 07:52:45]

This is how I start using "_" but I must admit is slowly became my equivalent
for for's "i". Anyway changed for "f".

     return dateFields.asDate();
   }
 
@@ -270,9 +265,7 @@ class DateFormat {
    * Given user input, attempt to parse the [inputString] into the anticipated
    * format, treating it as being in UTC.
    */
-  DateTime parseUTC(String inputString) {
-    return parse(inputString, true);
-  }
+  DateTime parseUTC(String inputString) => parse(inputString, true);
 
   /**
    * Return the locale code in which we operate, e.g. 'en_US' or 'pt'.
@@ -497,11 +490,9 @@ class DateFormat {
    * space to separate the two.
    */
   _appendPattern(String inputPattern, [String separator = ' ']) {
-    if (_pattern == null) {
-      _pattern = inputPattern;
-    } else {
-      _pattern = "$_pattern$separator$inputPattern";
-    }
+    _pattern = _pattern == null ?
+      inputPattern :
+      "$_pattern$separator$inputPattern";
   }
 
   /**
@@ -530,9 +521,7 @@ class DateFormat {
   get pattern => _pattern;
 
   /** Return the skeletons for our current locale. */
-  Map get _availableSkeletons {
-    return dateTimePatterns[locale];
-  }
+  Map get _availableSkeletons => dateTimePatterns[locale];
 
   /**
    * Return the [DateSymbol] information for the locale. This can be useful
@@ -583,8 +572,7 @@ class DateFormat {
 
     var parsed = _parsePatternHelper(
                       pattern.substring(matched.fullPattern().length));
-    parsed.add(matched);
-    return parsed;
+    return parsed..add(matched);

[Alan Knight, 2014/01/28 01:33:46]

I don't think I like this one. It eliminates the line, but it's too easy to miss
the cascade and be confused about what's going on.

[vicb, 2014/01/28 07:52:45]

I would prefer to keep this one. To me this is a Dart pattern devs will get used
to with time. It is also widely used elsewhere in Dart internal libs.
Thought ?

[Emily Fortuna, 2014/01/29 01:18:15]

I'm inclined to agree with Alan on this one. We use it in cases of
instantiation:
var list = new Set.from(oldSet)..add(newItem);

but for things as important as the return value of a function, I support being
more obvious.

[vicb, 2014/01/29 08:15:14]

reverted

[Alan Knight, 2014/01/29 18:41:35]

It doesn't look reverted. It looks like you moved the cascade up onto the
previous line. I'm saying I like it as three statements.

   }
 
   /** Find elements in a string that are patterns for specific fields.*/