Re: IDL: special DOMString that converts to Unicode

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