W3C home > Mailing lists > Public > public-script-coord@w3.org > January to March 2017

Extended attributes vs. new types

From: Domenic Denicola <d@domenic.me>
Date: Wed, 11 Jan 2017 23:11:58 +0000
To: Boris Zbarsky <bzbarsky@mit.edu>
CC: public-script-coord <public-script-coord@w3.org>
Message-ID: <CY1PR0501MB1369AC5B6EE5233A6301CD48DF660@CY1PR0501MB1369.namprd05.prod.outlook.com>
Hi Boris (cc public-script-coord for future reference),

I'm looking at tackling the shared array buffer + Web IDL issues discussed in https://www.w3.org/Bugs/Public/show_bug.cgi?id=29388 and related threads, and would appreciate some extra help walking me through the problems with extended attributes and union types you allude to in https://bugzilla.mozilla.org/show_bug.cgi?id=1231687#c17 (and which have motivated things like USVString in the past). I know you explained it briefly there, but I'm still a little lost, and feel that I need to get a solid grip on the issue if I'm to be productive here. So a more extensive explanation would be really appreciated.

Here are some questions whose answers might help me:

What exact steps would go wrong in the spec if we used [AllowShared] Uint8Array, or [EnsureUTF16] DOMString, instead of MaybeSharedUint8Array/USVString? What are the problematic Web IDL snippets, JS inputs, and spec steps that we end up at?

Why is this different than things like [Clamp] or [EnforceRange]? The way that they insert themselves into the JS -> Web IDL conversion steps seems totally reasonable to me. Does [Clamp] also break down when trying to use it with union types?

What spec surgery would be involved in fixing this whole situation? I guess the idea would be to make the extended attributes apply to the types instead of the arguments, but how exactly would that help?

Thanks!
-Domenic
Received on Wednesday, 11 January 2017 23:12:32 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 11 January 2017 23:12:33 UTC