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: Jonas Sicking <jonas@sicking.cc>
Date: Fri, 7 Jun 2013 09:14:05 -0700
Message-ID: <CA+c2ei9xtfnGs99CeaROFTRR-wR0C2yzf4j1Fx8t=XakwBO5Kw@mail.gmail.com>
To: Brendan Eich <brendan@secure.meer.net>
Cc: Boris Zbarsky <bzbarsky@mit.edu>, 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 Fri, Jun 7, 2013 at 4:35 AM, Brendan Eich <brendan@secure.meer.net> wrote:
>> 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?

FWIW, my understanding is that there's general agreement that the way
TreatUndefinedAs is defined in the WebIDL spec is wrong and needs to
be changed. The change is to make all optional arguments by default
treat an explicitly passed 'undefined' to an optional argument as
"argment not passed". Then TreatUndefinedAs can be used to override
that where other behavior is needed (I think mostly legacy APIs, if
it's needed at all).

/ Jonas
Received on Friday, 7 June 2013 16:15:07 UTC

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