- From: <bugzilla@jessica.w3.org>
- Date: Tue, 17 Jun 2014 19:11:43 +0000
- To: public-webapps-bugzilla@w3.org
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 the QA Contact for the bug.
Received on Tuesday, 17 June 2014 19:11:45 UTC