Move inline macro definition from typedarray.js to macros.py

Move inline macro definition from typedarray.js to macros.py

[haitao.feng, 2014-02-10 07:52:42]

This refactoring is needed when we implemented experimental Float32x4Array  and
Int32x4Array (https://github.com/johnmccutchan/ecmascript_simd). Otherwise we
need to copy the TYPED_ARRAY_CONSTRUCTOR macro definition inside an experimental
simd128.js file.

[Dmitry Lomov (no reviews), 2014-02-10 08:11:13]

On 2014/02/10 07:52:42, haitao.feng wrote:
> This refactoring is needed when we implemented experimental Float32x4Array 
and
> Int32x4Array (https://github.com/johnmccutchan/ecmascript_simd). Otherwise we
> need to copy the TYPED_ARRAY_CONSTRUCTOR macro definition inside an
experimental
> simd128.js file.

I do not like polluting global macros space with typed-array-related macros. 
The better solution would be to move Float32x4Array into typedarray.js in simd
patch.

In any case, since this patch will not affect main-line V8 in foreseeable
future, we should not put it into bleeding_edge.

[Yang, 2014-02-10 08:30:01]

On 2014/02/10 08:11:13, Dmitry Lomov (chromium) wrote:
> On 2014/02/10 07:52:42, haitao.feng wrote:
> > This refactoring is needed when we implemented experimental Float32x4Array 
> and
> > Int32x4Array (https://github.com/johnmccutchan/ecmascript_simd). Otherwise
we
> > need to copy the TYPED_ARRAY_CONSTRUCTOR macro definition inside an
> experimental
> > simd128.js file.
> 
> I do not like polluting global macros space with typed-array-related macros. 
> The better solution would be to move Float32x4Array into typedarray.js in simd
> patch.
> 
> In any case, since this patch will not affect main-line V8 in foreseeable
> future, we should not put it into bleeding_edge.

I agree.

[haitao.feng, 2014-02-11 03:11:19]

> I do not like polluting global macros space with typed-array-related macros. 
> The better solution would be to move Float32x4Array into typedarray.js in simd
> patch.

The typedarray.js is a builtin library but simd is an experimental library. The
simd stuff should not be inside the snapshot. The problem occurs for any
experimental feature which extends a builtin feature with inline macro
definitions.

[Dmitry Lomov (no reviews), 2014-02-11 06:30:02]

On 2014/02/11 03:11:19, haitao.feng wrote:
> > I do not like polluting global macros space with typed-array-related macros.

> > The better solution would be to move Float32x4Array into typedarray.js in
simd
> > patch.
> 
> The typedarray.js is a builtin library but simd is an experimental library.
The
> simd stuff should not be inside the snapshot. The problem occurs for any
> experimental feature which extends a builtin feature with inline macro
> definitions.

Tough. Polluting macros.py with typed array definitions is not the answer
either.
Here is an idea - provide for inclusion of one file into another, just for
macros, something like:
  use macros from 'typedarray.js';
Sounds appropriate, since simd.js in your patch is an experimental extension of
typedarray.js - seems like it should be able to use macros from the latter.
Other idea is to have typedarray-macros.py, just for these two files.

Either way, still does not belong on bleeding_edge.