Allen Wirfs-Brock (2014-02-21T23:29:52.000Z)
On Feb 21, 2014, at 3:16 PM, Brandon Benvie wrote:

> On 2/21/2014 3:08 PM, Allen Wirfs-Brock wrote:
>>> ```
>> Don't put too much weight into that. I've experiment with use the latter style when define some new methods to see where it is helpfully more descriptive. I just haven't bother to update all the legacy methods to use that same style. At some point in the near future I wall make a pass over the entire document and use consistent conventions for all function signatres -- either the ES3/5 style or the default value style. Given the amount of confusion the new style seems to have case, I may well revert to using the ES3/5 style.
>> 
> 
> Isn't there a problem with the new contention because some steps are either implicit or aren't done? For example, `end = this.length` in the ES5 style would have explicit ToObject conversion on `this` before getting its length.

Right,  my intend wasn't that those signature should ever be read as in any way normative. The actual algorithm steps always explicitly describe the parameter defaulting behavior when it is anything other than just use undefined.

Formerly we just would have used a signature heading like:
    Array.prototype.fill (value [, start [, end]])
it was hoping that something like
     Array.prototype.fill(value, start=0, end=this.length)
would be more usefully informative.

But in neither case is such a heading line intended to be an normative definition or syntactically valid  JS code.

Allen
domenic at domenicdenicola.com (2014-02-24T21:36:46.816Z)
Right,  my intend wasn't that those signature should ever be read as in any way normative. The actual algorithm steps always explicitly describe the parameter defaulting behavior when it is anything other than just use undefined.

Formerly we just would have used a signature heading like:

    Array.prototype.fill (value [, start [, end]])

it was hoping that something like

     Array.prototype.fill(value, start=0, end=this.length)

would be more usefully informative.

But in neither case is such a heading line intended to be an normative definition or syntactically valid  JS code.