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

Re: [Futures] accept/resolve/reject on a resolver don't have clearly defined behavior if no value is passed

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Fri, 07 Jun 2013 12:04:22 -0400
Message-ID: <51B20486.3080508@mit.edu>
To: Brendan Eich <brendan@secure.meer.net>
CC: Jonas Sicking <jonas@sicking.cc>, DOM public list <www-dom@w3.org>, Anne van Kesteren <annevk@annevk.nl>, Cameron McCormack <cam@mcc.id.au>, "public-script-coord@w3.org" <public-script-coord@w3.org>
On 6/7/13 7:35 AM, Brendan Eich wrote:
> That is, if you have ES3 or ES5 code of this form:
>    function f(a, b) {
>      a = a || 4;
>      b = b || 5;
>      return g.apply(undefined, arguments);
>    }
> The ES6 way to write it is to avoid arguments altogether:
>    function f(a = 4, b = 5, ...r) {
>      return g(a, b, ...r);
>    }

OK, that makes sense to me.  I'm mostly worried about impedance 
mismatches between libraries that currently use apply and arguments with 
abandon and webidl APIS, but maybe in practice this will be a nonissue....

>> In any case, the question is how to reconcile the two sanely.  Once
>> that's done, I fully expect the simplicity of the C++ implementation
>> here to be nonexistent.
> Ouch. But didn't TreatUndefinedAs in all its glory already do most of
> the damage?

No, the thing doing the damage here is that a C++ implementation doesn't 
really want to use "undefined" to indicate "not passed" since there is 
no such value in C++ to start with, and bridging that impedance mismatch 
ends up ugly unless the IDL is clearly annotated with the exact 
semantics undefined should have in particular cases.

Received on Friday, 7 June 2013 16:05:05 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:13 UTC