Create 'unified' version of Date, with a dart2js implementation.

Create 'unified' version of Date, with a dart2js implementation.

VM implementation is pending.

This also fixes dart2js, so it correctly handles getters and setters in
patches.

BUG=

Committed: https://code.google.com/p/dart/source/detail?r=10116

[Mads Ager (google), 2012-08-01 08:08:31]

LGTM!

Florian, could you have a look at the dart2js compiler change. I'm a bit
confused about the two patch elements for getters and setters. Could you help us
double check that skipping accessors and using the abstract field is the right
thing to do?

https://chromiumcodereview.appspot.com/10829102/diff/2001/corelib/unified/cor...
File corelib/unified/core/implementation/date.dart (right):

https://chromiumcodereview.appspot.com/10829102/diff/2001/corelib/unified/cor...
corelib/unified/core/implementation/date.dart:117: external String get
timeZoneName();
Maybe group all of the external methods at the end or top of the block of
methods to make them stand out as much as possible? Also, I think I would remove
the newlines between them since there is no implementation.

https://chromiumcodereview.appspot.com/10829102/diff/2001/lib/compiler/implem...
File lib/compiler/implementation/compiler.dart (right):

https://chromiumcodereview.appspot.com/10829102/diff/2001/lib/compiler/implem...
lib/compiler/implementation/compiler.dart:560: // Skip accessors, since we
handle them in the abstract field case.
Does this mean that there is both an accessor and an abstract field patch
element in the list for a getter or setter?

[Anders Johnsen, 2012-08-01 08:35:50]

https://chromiumcodereview.appspot.com/10829102/diff/2001/corelib/unified/cor...
File corelib/unified/core/implementation/date.dart (right):

https://chromiumcodereview.appspot.com/10829102/diff/2001/corelib/unified/cor...
corelib/unified/core/implementation/date.dart:117: external String get
timeZoneName();
On 2012/08/01 08:08:31, Mads Ager wrote:
> Maybe group all of the external methods at the end or top of the block of
> methods to make them stand out as much as possible? Also, I think I would
remove
> the newlines between them since there is no implementation.

As I see it, we have two options. Keeping them in line with the interface
ordering or moving them to the bottom. Moving them to the bottom for now.

https://chromiumcodereview.appspot.com/10829102/diff/2001/lib/compiler/implem...
File lib/compiler/implementation/compiler.dart (right):

https://chromiumcodereview.appspot.com/10829102/diff/2001/lib/compiler/implem...
lib/compiler/implementation/compiler.dart:560: // Skip accessors, since we
handle them in the abstract field case.
On 2012/08/01 08:08:31, Mads Ager wrote:
> Does this mean that there is both an accessor and an abstract field patch
> element in the list for a getter or setter?

Yep. It's a invariant on the AST. I've updated the comment to be more clear
about this.

[floitsch, 2012-08-01 09:05:01]

LGTM, but I'm not really the right person for the abstract fields and
getters/setters.
Looping in Peter, too.

https://chromiumcodereview.appspot.com/10829102/diff/7001/lib/compiler/implem...
File lib/compiler/implementation/compiler.dart (right):

https://chromiumcodereview.appspot.com/10829102/diff/7001/lib/compiler/implem...
lib/compiler/implementation/compiler.dart:560: // Skip accessors. An accessor
always have an abstract field,
has

https://chromiumcodereview.appspot.com/10829102/diff/7001/lib/compiler/implem...
lib/compiler/implementation/compiler.dart:561: // representing the accessor in
the lookup scope. We can then always
We can thus skip the accessor and just handle the abstract field.

https://chromiumcodereview.appspot.com/10829102/diff/7001/lib/compiler/implem...
File lib/compiler/implementation/lib/coreimpl.dartp (right):

https://chromiumcodereview.appspot.com/10829102/diff/7001/lib/compiler/implem...
lib/compiler/implementation/lib/coreimpl.dartp:54: var day =
Primitives.getWeekday(this);
We should be consistent: either we let the Primitives deal with the different
offsets, or we deal with them here.
In particular: Primitives.getMonth(this) needs to map from JS 0-based to Dart's
1-based months. The mapping from JS' weekday to Dart's weekday should happen at
the same level.

[Anders Johnsen, 2012-08-01 09:15:38]

https://chromiumcodereview.appspot.com/10829102/diff/7001/lib/compiler/implem...
File lib/compiler/implementation/compiler.dart (right):

https://chromiumcodereview.appspot.com/10829102/diff/7001/lib/compiler/implem...
lib/compiler/implementation/compiler.dart:560: // Skip accessors. An accessor
always have an abstract field,
On 2012/08/01 09:05:01, floitsch wrote:
> has

Done.

https://chromiumcodereview.appspot.com/10829102/diff/7001/lib/compiler/implem...
lib/compiler/implementation/compiler.dart:561: // representing the accessor in
the lookup scope. We can then always
On 2012/08/01 09:05:01, floitsch wrote:
> We can thus skip the accessor and just handle the abstract field.

Done.

https://chromiumcodereview.appspot.com/10829102/diff/7001/lib/compiler/implem...
File lib/compiler/implementation/lib/coreimpl.dartp (right):

https://chromiumcodereview.appspot.com/10829102/diff/7001/lib/compiler/implem...
lib/compiler/implementation/lib/coreimpl.dartp:54: var day =
Primitives.getWeekday(this);
On 2012/08/01 09:05:01, floitsch wrote:
> We should be consistent: either we let the Primitives deal with the different
> offsets, or we deal with them here.
> In particular: Primitives.getMonth(this) needs to map from JS 0-based to
Dart's
> 1-based months. The mapping from JS' weekday to Dart's weekday should happen
at
> the same level.

Done.

[ahe, 2012-08-02 13:47:54]

The changes to compiler.dart looks fine, but in the future, it would be great if
you can split library unification work and compiler work in separate CLs. Also,
please don't forget to add unit tests.