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?

Received on Wednesday, 11 January 2017 23:12:32 UTC

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