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

https://www.w3.org/Bugs/Public/show_bug.cgi?id=23369

--- Comment #40 from Allen Wirfs-Brock <allen@wirfs-brock.com> ---
(In reply to Ryan Sleevi from comment #39)

> 
> So, I think we may be a bit off into the woods about what the "normal" ES
> developer would do. ...
> 

We should be trying to understand, encourage, and design APIs to a native JS
style rather than picking and choosing among styles derived from other
languages. 

> 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.

It's an excellent solution for situations where there is a 1:1 correspondence
between ArrayBufferViews and ArrayBuffers. My hypothesis is that this will be
the most common situation and a very idiomatic JS approach. Particularly if an
overall functional style using immutable data is being used.  

> 
> In the priority of constituencies, it feels like makeImmutable() is probably
> the wrong approach; it forces this overhead onto callers.

Which, to me, seems like exactly where it belongs. Your API design is always
copying, even if the data is already stable and/or logically immutable.  It's
the author of the calling code that understands which of the various possible
data management policies they are using and hence whether or not copying is
needed. You, on the other hand, have to pessimistically assume that copying is
always needed.

The ability for an ArrayBuffer to be marked as immutable would allow your API
layer to recognize when copying is not needed. 


> 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)
> 

I don't think any of the examples you list are particularly good exemplars of a
a natural idiomatic JS style we should be looking for in new APIs. 

> 
> 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.

Sure, and let's also allow for immutable ArrayBuffers so can recognize and
optimize for that common case.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Thursday, 19 June 2014 20:24:31 UTC