Remove dead code path (typed array interfaces)

Remove dead code path (typed array interfaces)

Typed arrays all have custom bindings, so code path that checks if an
interface is a typed array (IsTypedArray($interfaceName)) is dead code.

This removes it to avoid being misleading (and clarify rewrite);
no changes to generated code.

Obviously we want to remove these custom bindings, but the existing dead
code isn't helpful.

R=haraken

Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=165039

[haraken, 2014-01-14 04:49:56]

LGTM.

Though I wonder why typed arrays are written in custom bindings. We should
auto-generate the typed-array bindings at some point.

[Nils Barth (inactive), 2014-01-14 05:23:35]

On 2014/01/14 04:49:56, haraken wrote:
> Though I wonder why typed arrays are written in custom bindings. We should
> auto-generate the typed-array bindings at some point.

Agreed -- typed arrays are 1690 lines of custom bindings (15% of total!), and
should be removable all together.
I've put this at the top of my Custom Bindings removal list.

[commit-bot: I haz the power, 2014-01-14 05:25:50]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/nbarth@chromium.org/129793007/1

[haraken, 2014-01-14 05:26:44]

On 2014/01/14 05:23:35, Nils Barth wrote:
> On 2014/01/14 04:49:56, haraken wrote:
> > Though I wonder why typed arrays are written in custom bindings. We should
> > auto-generate the typed-array bindings at some point.
> 
> Agreed -- typed arrays are 1690 lines of custom bindings (15% of total!), and
> should be removable all together.
> I've put this at the top of my Custom Bindings removal list.

!!

My concern is that those custom bindings have toV8(), wrap() etc. They're really
buggy to hand-write.

[Nils Barth (inactive), 2014-01-14 05:27:54]

On 2014/01/14 05:26:44, haraken wrote:
> My concern is that those custom bindings have toV8(), wrap() etc. They're
really
> buggy to hand-write.

Got it, thanks!

[Dmitry Lomov (no reviews), 2014-01-14 06:55:21]

On 2014/01/14 05:27:54, Nils Barth wrote:
> On 2014/01/14 05:26:44, haraken wrote:
> > My concern is that those custom bindings have toV8(), wrap() etc. They're
> really
> > buggy to hand-writ
> 
> Got it, thanks!

Think carefully about whether you really want to do this and wouldn't this be
just shuffling complexity around from plain C++ into generator (which is already
over-complex).
The fact is, typed arrays have custom bindings because they are special -
namely, their counter-objects in JavaScript heap are not defined in Blink, so
coming from FunctionTemplates, but are native  V8 objects (V8::Uint8Array and
such). Current implementation carefully templetize everything in various
variations, so that there is only one (templetized) implementation of toV8 and
toNative for all typed arrays.  This implementation is significantly different
from the code produced by the code generator, and if you push that
implementation into a code generator, you will just shovel that under the rug
and the code generator will become even more a maze of twisted passages, all
different.

The real improvement here will be to provide a sufficiently generic template
versions of toV8, toNative, createWrapper and such that generated bindings and
custom bindings can just delegate to that templetized version.

[Nils Barth (inactive), 2014-01-14 07:46:16]

On 2014/01/14 06:55:21, Dmitry Lomov (chromium) wrote:
> Think carefully about whether you really want to do this and wouldn't this be
> just shuffling complexity around from plain C++ into generator (which is
already
> over-complex).
> The fact is, typed arrays have custom bindings because they are special -
> namely, their counter-objects in JavaScript heap are not defined in Blink, so
> coming from FunctionTemplates, but are native  V8 objects (V8::Uint8Array and
> such). Current implementation carefully templetize everything in various
> variations, so that there is only one (templetized) implementation of toV8 and
> toNative for all typed arrays.  This implementation is significantly different
> from the code produced by the code generator, and if you push that
> implementation into a code generator, you will just shovel that under the rug
> and the code generator will become even more a maze of twisted passages, all
> different.
> 
> The real improvement here will be to provide a sufficiently generic template
> versions of toV8, toNative, createWrapper and such that generated bindings and
> custom bindings can just delegate to that templetized version.

Thanks Dmitry - this is very helpful!
I'm not working on this currently (instead doing compiler rewrite),
but when I do take a look at it, I'll bear this in mind and work to do it
sensibly,
not just shuffling complexity around.

[commit-bot: I haz the power, 2014-01-14 08:03:55]

Change committed as 165039