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

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

--- Comment #21 from Allen Wirfs-Brock <allen@wirfs-brock.com> ---
(In reply to Ryan Sleevi from comment #20)
> (In reply to Allen Wirfs-Brock from comment #19)
> > Web platform APIs should start out as good idiomatic ES API and then get
> > refined, if necessary, to ensure any platform invariants. Not the other way
> > around.
> 
> I think we're actually in violent agreement here; 

Coo!
> 
> ... 
> My request is that this sort of language be incorporated (optionally) as
> part of WebIDL, so that a more meaningful short-hand can emerge, and that
> conventions can be consistently identified.
> 
> That is, imagine an attribute on function arguments that is similar to
> [TreatNullAs=] that indicates how the incoming %TypedArray% type should be
> handled, as part of the ES->WebIDL type conversion.

I see two issues, the bigger one is on how exactly to generalize the sort of
cloning you describe in your spec.  More on that below.

The second issue is that, to me, the need to do this sort of cloning should be
relatively rare and should be backed up by some sort of analysis that justifies
it. If it is too easy for an API designer say that n argument value should be
cloned that might lead to a tendency for some API designers to clone everything
without really having thought through whether the clone is essential.

For example, in the WebCrypot API I notice that the encrypt and decrypt methods
both are specified to clone their data parameters. Why? It certainly doesn't
make any sense to modify the data buffer after the initial call and before
processing starts, but is there any integrity or other essential reasons that
must be actively guarded against with the cost of forcing a copy of a
potentially large buffer? Also, is the a reason that the CryptoKey parameter
objects aren't cloned (probably deeply) to ensure that it isn't mutated at the
same time a buffer might be mutated?

> 
> > If there are integrity issues involved, you may need to explicitly copy. 
> > But it many other situations such copying will be too expensive and it will
> > be perfectly adequate to document that the passed data structures should not
> > be accessed or modified by the caller until the result promise has been
> > settled. What if the caller violates that restriction?  It's a programmer
> > bug just like missions of other possible programming bugs.
> 
> Again, more violent agreement; there are times where copying is appropriate,
> and times when copying is not appropriate.
> 
> When copying is appropriate or desired for a general platform API, it's
> desirable to have that copying behaviour behave consistently across
> conforming WebIDL specifications. That is, much in the same way that the
> Object->Dictionary conversion is defined (down to the order of how fields
> are accessed), it would be "Nice" / "Good" to have a similar method, as part
> of WebIDL, to indicate how TypedArrays are handled for Promise returning
> specifications. That's all I was requesting.

Which gets us back to my first issue.  It easy to say what it means to clone a
binary buffer. But as soon as you get anything more complicated a generalized
meaning of clone becomes less clear.  With ES6 we have the possibility of user
defined subclasses of the built-in typed array types existing and they can add 
own properties to the array instances. Does a clone need to copy them? It
probably depends on the usage and the motivation for the clone. 

If we're talking about any sort of real object graph (for example, a
CryptKey??) a generalized clone operation is much more problematic. 

To the degree the are only talking about cloning binary data this seems
reasonable but as soon has we get any object references involved its much less
clear what a general solution might be (or even what the general problem is).

> 
> > You are taking the approach that WebIDL is defining "first-class" behavior
> > and that makes everything else an ES programmer does "second-class".  That's
> > just backwards.
> 
> I fear you've misunderstood the intent, as it's certainly not the case. My
> comparison of first and second class has nothing to do with ES-vs-WebIDL,
> and is solely about WebIDL-vs-prose (as in the example of WebCrypto), where
> typed annotations are vastly less likely to result in bugs or implementation
> errors than prose is, and is vastly more likely to be consistent across
> multiple independent specifications.

Cool.  Sorry I misunderstood your approach.  BTW, on a pretty much separate
matter I'm not really convinced that you need to allow either an ArrayBuffer or
a typed array for all of these data arguments.  I understand, the desire to be
flexible but that complicates each API to a certain extent and also muddles the
abstraction over which the APIs operate. I'd choose one or the other (I'd
probably to the array route).  It's easy enough for an ES programmer to wrap a
typed array instance around an ArrayBiuffer if that is what they have in hand.

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

Received on Tuesday, 17 June 2014 21:14:56 UTC