W3C home > Mailing lists > Public > public-script-coord@w3.org > April to June 2014

[Bug 23369] Provide hooks for Typed Arrays (ArrayBuffer and friends)

From: <bugzilla@jessica.w3.org>
Date: Thu, 19 Jun 2014 01:07:12 +0000
To: public-script-coord@w3.org
Message-ID: <bug-23369-3890-lewFnicsBq@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23369

--- Comment #39 from Ryan Sleevi <sleevi@google.com> ---
(In reply to Allen Wirfs-Brock from comment #38)
> This sort of ES based thinking really should be a factor in your API
> designs. Don't assume that the ES developer will approach problems just like
> a C++ developer.

So, I think we may be a bit off into the woods about what the "normal" ES
developer would do. That is, ES developers come from all sorts of backgrounds.
They may not approach it like C/C++ - they may come from a C# or Java
background, knowing about the immutability of strings and the importance of
StringBuilder, and thus be similarly paranoid. They may come from a gaming
background, and know how gc stalls can kill you, and thus do everything they
can to reduce gc.

As it relates to this specific issue: The makeImmutable() proposal has two key
downsides, in my mind:

1) It doesn't have a good solution for ArrayBufferView, short of copying into a
newly-minted immutable array
2) It forces authors (such as the example I gave) to explicitly copy, even if
they did *want* to optimize.

In the priority of constituencies, it feels like makeImmutable() is probably
the wrong approach; it forces this overhead onto callers. As to whether
(ArrayBufferView) is a valid input to most APIs - I would just note that it's
seemingly in use by most APIs that take binary data as inputs (Web GL, Web
Audio, there's an open bug for MSE, Web Crypto)

Now, I'm biased because I'm thinking in the context of cryptographic operations
and Web Crypto, and still strongly believe that "don't do that" is a bad
answer. From the sampling of the other APIs, though, it does seem that for
complex data processing (eg: the APIs that do tend to take ArrayBuffers), if
they're going to behave asynchronously (via Promises), they copy.

Indeed, even the synchronous APIs, such as WebGL, seem to result in copying in
most implementations. That is, because WebGL calls themselves tend to have
synchronous overheads, implementations are deferring the operations (which have
void returns, and thus can return immediately), and as long as they ensure a
consistency in the ordering of WebGL operations, this is perfectly legal!

I agree, there are things unaddressed - complex object trees that are preserved
as platform objects (IDL annotation 'object' or 'any'). Frankly, I'm not too
bothered by this - we don't need to boil the ocean. We should come with a good
set of prose though for the non-simple data type that might be mutated. Strings
are immutable, as are Numbers, thus WebIDL is good and fine. ArrayBuffers are
mutable, hence it's good to include in WebIDL how authors MAY handle them.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Received on Thursday, 19 June 2014 01:07:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:22 UTC