Re: IDL: special DOMString that converts to Unicode

On Sun, Jul 28, 2013 at 12:27 PM, Anne van Kesteren <annevk@annevk.nl> wrote:
> On Tue, Jul 23, 2013 at 1:41 AM, Cameron McCormack <cam@mcc.id.au> wrote:
>> I've added the [EnsureUTF16] extended attribute now.
>>
>> http://dev.w3.org/2006/webapi/WebIDL/#EnsureUTF16
>> http://dev.w3.org/cvsweb/2006/webapi/WebIDL/Overview.xml.diff?r1=1.646;r2=1.647;f=h
>
> So actually an attribute does not work. Either this needs to be a type
> or we should just go back to using the algorithm we have in IDL.
>
> There are various places in the platform that assume Unicode scalar
> values as input (e.g. the URL parser, encodings). This extended
> attribute does not give them that, it still hands them code units.

Why does an extended attribute not provide this? It seems like an
implementation detail if

[EnsureUTF16] DOMString

hands the backing implementation a string in UTF8, UTF16, UTF32 or
something else. I.e. there is no requirement that the WebIDL
implementation hands the backing code something that is the same
format as a DOMString. All that the above requires is that the backing
code is handed something that can be converted to unicode without
decoding errors.

So it seems like it provides the same guarantees and flexibility as
something like

UnicodeString

or anything similar would.

/ Jonas

Received on Sunday, 28 July 2013 23:09:02 UTC