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: Tue, 17 Jun 2014 19:11:43 +0000
To: public-script-coord@w3.org
Message-ID: <bug-23369-3890-9OCFmxDRg4@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23369

--- Comment #20 from Ryan Sleevi <sleevi@google.com> ---
(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; 

WebAudio, as a bad example, uses pseudo-neutering of objects. That doesn't
really work, because it's not valid ES.

WebCrypto handles this in terms of ES primitives and ES-language; see
https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#concept-clone-CryptoOperationData

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.

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

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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Received on Tuesday, 17 June 2014 19:11:45 UTC

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