Re: IDL: special DOMString that converts to Unicode

On Oct 30, 2012, at 4:16 AM, Jonas Sicking wrote:

> On Tue, Oct 30, 2012 at 10:01 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
>> On Mon, Oct 29, 2012 at 6:20 PM, Brendan Eich <brendan@mozilla.org> wrote:
>>> In general, interface != implementation. Possibly these interfaces really
>>> are implementation-specific, but suppose I want to implement XHR's
>>> interfaces in JS and pass them off to a testsuite. Would the JS
>>> implementation have to validate? Should it?
>> 
>> No UTFString means the same as DOMString except that lone surrogates
>> get replaced with U+FFFD. There's no exception throwing related to it.
>> I would classify this as an effect at the binding level as either the
>> string stays a sequence of code units or it gets converted to a
>> sequence of code points.
>> 
>> I agree that we should not use UTFString for cases where
>> http://encoding.spec.whatwg.org/ is not involved and Web IDL should
>> probably indicate something to that effect. We could name it
>> "CodePointString" maybe so people are more likely to pick the shorter
>> variant (as they should), but in the end implementors should review
>> specifications as well before they implement them and if they use
>> UTFString/CodePointString incorrectly it should be fixed at that
>> point.
> 
> An alternative is to express this as an extended attribute rather than a type.
> 
> / Jonas
> 

This is the sort of computationally expensive operation that we would express in the ECMAScript specification as an "Abstract Operation"  (a pseudo code subroutine).  It would then be "called" by the specification algorithms of the specific methods that require it.

This both standardizes the specification of the algorithm and limits its span of attention to only the specific places that really need it and whose authors should already be aware of that need.

If you make something like UTFString that is rarely needed a "type" or even an "attribute" it brings it to the attention of everybody who writes an interface description.  As an item in the list of available WebIDL types or attributes, it must be thought about every time somebody specifies a signature that includes a "string" parameter.  They have to think, "Do I need a DOMString, or should this be a UTFString"  or "Should I place the "UTFSTring" attribute on this parameter?".  Some API designers, some of the time will misunderstand the intended usage and use the UTF type/attribute when it isn't needed.

So far, in this thread I haven't seen anything that suggests that UTFString should be defined at the language-level of WebIDL.  It is just one of the thousands of constraints and invariants that occur as part of the specification of the various web app platform.  Very very few of these can or should be built in to WebIDL. They are a concern for specific APIs not things that span all possible APIs.

Allen

Received on Tuesday, 30 October 2012 16:43:46 UTC