W3C home > Mailing lists > Public > public-script-coord@w3.org > July to September 2013

Re: IDL: special DOMString that converts to Unicode

From: Jonas Sicking <jonas@sicking.cc>
Date: Sun, 28 Jul 2013 16:38:14 -0700
Message-ID: <CA+c2ei9L18QqBJgZnZuiOaR9VCSmgT8AoA95Yzyru-bFaG01bg@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: Cameron McCormack <cam@mcc.id.au>, Brendan Eich <brendan@mozilla.org>, Allen Wirfs-Brock <allen@wirfs-brock.com>, Simon Pieters <simonp@opera.com>, Robin Berjon <robin@w3.org>, "public-script-coord@w3.org" <public-script-coord@w3.org>
On Sun, Jul 28, 2013 at 4:33 PM, Anne van Kesteren <annevk@annevk.nl> wrote:
> On Sun, Jul 28, 2013 at 4:08 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>> 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.
>
> It is not defined as such at the moment. I sorta expected extended
> attributes to be modifiers within the value space always and not
> represent another type underneath that's translated back and forth at
> the boundaries. If we want it to that too, we should probably also
> change ByteString into an extended attribute, but it seems somewhat
> weird design-wise to me.

[EnsureUTF16] is a modifier within the value space, no? It makes the
function throw if specific values are provided, but it doesn't mean
that new values can be expressed. Just like [EnforceRange] does.

And yes, I think ByteString could, and probably should, be done as an
extended attribute.

/ Jonas
Received on Sunday, 28 July 2013 23:39:15 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:37:50 UTC