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

Re: Reconciling handling of optional arguments and handling of default values across ES and webidl

From: Andreas Rossberg <rossberg@google.com>
Date: Thu, 9 May 2013 17:11:52 +0200
Message-ID: <CADjR9Npn+zgP8JLAO4AT8ssjJmMQz7aEZujJ1VsBHvDuUXCA3w@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: Allen Wirfs-Brock <allen@wirfs-brock.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>
On 9 May 2013 15:45, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 5/9/13 8:14 AM, Andreas Rossberg wrote:
>>
>> On 9 May 2013 03:18, Boris Zbarsky <bzbarsky@mit.edu> wrote:
>>>
>>> I guess let's take this requirement for ES as a sunk compatibility cost.
>>> Where do we go with WebIDL?
>>
>> Maybe I misunderstand, but is there any reason why WebIDL needs to
>> care about the arguments object at all?
>
> [...]
>
> Right now WebIDL can express something like "not passed or coerced to
> string" (which looks like "optional DOMString"), and it can express "not
> passed or just any value" (which is "optional any"), but can't express "not
> passed, or explicit undefined, or coerced to string".  One question is
> whether it ever needs to do that or whether we can assume that any cases
> that want to treat "not passed" and "undefined" differently would always
> want the 'any' type anyway.

I think existing JS legacy notwithstanding it is generally bad
practice for an API to make an observable distinction between passing
undefined and not passing anything, especially in the light of ES6's
treatment of defaults. So I don't think a higher-level declarative
mechanism like WebIDL should ever want to support that. But perhaps
others disagree.

/Andreas
Received on Thursday, 9 May 2013 15:12:39 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:37:49 UTC