Re: IDL: special DOMString that converts to Unicode

Simon Pieters wrote:
> On Mon, 29 Oct 2012 17:57:01 +0200, Brendan Eich <brendan@mozilla.org> 
> wrote:
>
>>> I listed the APIs this affects. They are indeed mostly when things hit
>>> the wire such as URLs and networking.
>>
>> Sorry I missed it -- but is it "quite a number" of APIs? That's still 
>> in tension with "only" in Simon's reply.
>
> I don't see how it's useful to discuss the wording here. Anne listed 
> the APIs that use this today. I pointed out that we don't want APIs 
> that don't need this to accidentally use it.

Sorry, not to make a mountain out of it -- but lack of acknowledgement 
makes me repeat (one time only).

If it doesn't matter, let's add more types freely. Clearly that could go 
wrong, so a principled discussion is in order.

>
>> Does the Unicode correctness requirement in implementations of these 
>> APIs really require a new type in WebIDL, though?
>
> We could continue doing what we do now, or we could do what Anne 
> proposed, or we could do something else like having centralized rules 
> defined *somewhere* that specs can hook into.

Or we could annotate interfaces (no centralization) but not abuse 
parameter types and add new types.

The new parameter type seems to say that the JS binding layer has to 
validate. This could be observable if effects can arise before an 
exception is thrown. We do want the throw to come before any effects, 
but it seems to me this does not require a new parameter type.

>
>> Adding a new type makes mischief:
>>
>> * It may be used elsewhere than for interfaces to implementations 
>> that need to check for valid Unicode encoding. s/may/will/ there, 
>> Murphy says.
>
> (This is the same as the concern I raised with calling it "string".)

Got it, thanks for pointing that out.

>> * It puts the burden on the JS engine via WebIDL bindings, rather 
>> than on the implementation.
>
> I'm not convinced this is really the case -- the requirements in specs 
> can usually be satisfied in any manner so long as the end result is 
> equivalent to that of the spec. That said, it might make more sense to 
> specify things that are closer to how they get implemented.

Yes, it's not clear-cut -- not a clear win doing a new type. Given the 
other issues with a new type, I'm pushing back. This seems like a good 
thing to discuss, not a slam dunk either way.

>
>> Is this desirable? It might very well be better for the 
>> implementations to do the checking, to avoid two passes over strings.
>>
>> * It mixes contingent implementation details into interface. Are the 
>> interfaces you listed really concrete implementation APIs, or might 
>> they be used (in the future if not now) for implementations that do 
>> not need to sanitize?
>
> I'm not sure I follow this point. Can you give an example of such a 
> case, hypothetical or real?

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?

/be

>
> cheers

Received on Monday, 29 October 2012 17:21:09 UTC