If a term is not explicitly defined by the spec. then the English dictionary
definition applies: "4) being with one or others or in the specified or
understood place"
This is further clarified by the introductory paragraphs of chapter 15 that
say: "Unless otherwise specified...if a function or constructor described in
this clause is given fewer arguments than the function is specified to require,
the function or constructor shall behave exactly as if it had been given
sufficient additional arguments, each such argument being the undefined value."
Testing is an argument is present is an "otherwise specified" situation. In
other words, of an argument is not present then it is treated as if the value
is undefined. In general, the specification test for undefined as an argument
position if it doesn't care whether or not an explicit undefined was passed.
Any time the spec. says "if argument foo is present..." it could be restate by
"if the number of explicitly passed arguments is >= foo's argument position..."
On May 31, 2013, at 4:33 AM, Till Schneidereit wrote:
> I couldn't find any precise definition for the spec term "present", so this
> is not entirely clear to me.
>
> Example:
> In step 7 of 15.4.3.21 Array.prototype.reduce, a TypeError must be thrown if
> the optional argument `initialValue` isn't present. If a value of `undefined`
> does *not* cause the argument to be present, that function can be implemented
> with the following signature:
>
> `function ArrayReduce(callbackfn, initialValue = undefined)`
>
> If, however, the value `undefined` means that the argument is present, the
> signature should probably be:
>
> `function ArrayReduce(callbackfn, ...rest)`
or you could define it as:
const missing = {};
function ArrayReduce(callbackfn, initValue=missing) {
....
//step 7
if (len === 0 && initialValue === missing) throw new TypeError("initial
value required");
>
> The question isn't entirely academic, as I'm trying to get the self-hosted
> implementations of builtins in SpiderMonkey to be as close to the spec as
> possible.
that better be semantically identical to the spec...
Allen
>
>
> thanks,
> till
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
