[date] Migrate Date field accessors to native builtins.

[date] Migrate Date field accessors to native builtins.

There's no reason to have JavaScript wrappers for those accessors,
since the meat is already in hand-written native code (via %_DateField).
First step now to put them into native builtins. Next step will be to
completely remove %_DateField.

R=yangguo@chromium.org

Committed: https://crrev.com/fc5c7e0486038f8a615041963a13c9b7bb602469
Cr-Commit-Position: refs/heads/master@{#33172}

[Benedikt Meurer, 2016-01-08 12:27:17]

Description was changed from

==========
[date] Migrate Date field accessors to native builtins.
==========

to

==========
[date] Migrate Date field accessors to native builtins.

There's no reason to have JavaScript wrappers for those accessors,
since the meat is already in hand-written native code (via %_DateField).
First step now to put them into native builtins. Next step will be to
completely remove %_DateField.

R=yangguo@chromium.org
==========

[Benedikt Meurer, 2016-01-08 12:27:17]

bmeurer@chromium.org changed reviewers:
+ yangguo@chromium.org

[Benedikt Meurer, 2016-01-08 12:27:34]

Hey Yang,

Another cleanup step to date.js.
Please take a look.

Thanks,
Benedikt

[Yang, 2016-01-08 12:36:48]

On 2016/01/08 12:27:34, Benedikt Meurer wrote:
> Hey Yang,
> 
> Another cleanup step to date.js.
> Please take a look.
> 
> Thanks,
> Benedikt

The old implementation were not wrappers, right? %_DateField gets inlined so we
don't have any indirection, and the code should be almost the same, the only
difference being that one code is compiled as function code and the other
generated as builtins. If anything, the former is a bit nicer since it's
compiled lazily on-demand, and may be even inlinable in the future.

I don't generally have a problem with the new implementation, but it seems like
we cannot (yet) remove the old one (code generators for %_DateField and macros
in macros.py), so now we simply ended up with two competing implementations?

[Yang, 2016-01-08 12:40:24]

On 2016/01/08 12:36:48, Yang wrote:
> On 2016/01/08 12:27:34, Benedikt Meurer wrote:
> > Hey Yang,
> > 
> > Another cleanup step to date.js.
> > Please take a look.
> > 
> > Thanks,
> > Benedikt
> 
> The old implementation were not wrappers, right? %_DateField gets inlined so
we
> don't have any indirection, and the code should be almost the same, the only
> difference being that one code is compiled as function code and the other
> generated as builtins. If anything, the former is a bit nicer since it's
> compiled lazily on-demand, and may be even inlinable in the future.
> 
> I don't generally have a problem with the new implementation, but it seems
like
> we cannot (yet) remove the old one (code generators for %_DateField and macros
> in macros.py), so now we simply ended up with two competing implementations?

as discussed offline, as long as the plan is to remove the old impl, lgtm.

[Benedikt Meurer, 2016-01-08 12:41:17]

The CQ bit was checked by bmeurer@chromium.org

[commit-bot: I haz the power, 2016-01-08 12:41:24]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1567353002/20001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1567353002/20001

[commit-bot: I haz the power, 2016-01-08 12:42:53]

Description was changed from

==========
[date] Migrate Date field accessors to native builtins.

There's no reason to have JavaScript wrappers for those accessors,
since the meat is already in hand-written native code (via %_DateField).
First step now to put them into native builtins. Next step will be to
completely remove %_DateField.

R=yangguo@chromium.org
==========

to

==========
[date] Migrate Date field accessors to native builtins.

There's no reason to have JavaScript wrappers for those accessors,
since the meat is already in hand-written native code (via %_DateField).
First step now to put them into native builtins. Next step will be to
completely remove %_DateField.

R=yangguo@chromium.org
==========

[commit-bot: I haz the power, 2016-01-08 12:42:53]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2016-01-08 12:43:18]

Description was changed from

==========
[date] Migrate Date field accessors to native builtins.

There's no reason to have JavaScript wrappers for those accessors,
since the meat is already in hand-written native code (via %_DateField).
First step now to put them into native builtins. Next step will be to
completely remove %_DateField.

R=yangguo@chromium.org
==========

to

==========
[date] Migrate Date field accessors to native builtins.

There's no reason to have JavaScript wrappers for those accessors,
since the meat is already in hand-written native code (via %_DateField).
First step now to put them into native builtins. Next step will be to
completely remove %_DateField.

R=yangguo@chromium.org

Committed: https://crrev.com/fc5c7e0486038f8a615041963a13c9b7bb602469
Cr-Commit-Position: refs/heads/master@{#33172}
==========

[commit-bot: I haz the power, 2016-01-08 12:43:19]

Patchset 2 (id:??) landed as
https://crrev.com/fc5c7e0486038f8a615041963a13c9b7bb602469
Cr-Commit-Position: refs/heads/master@{#33172}