On Aug 15, 2012, at 5:09 PM, David Bruant wrote: > Le 14/08/2012 04:16, Allen Wirfs-Brock a écrit : >> check out the current ES66 spec. draft. Based upon discussions at the >> March TC39 meeting hypot2 was eliminated and an optional third >> argument as added to hypot. > Quoting relevant part of the March meeting notes [1]: > ... >> Waldemar, MarkM: Why not one or zero arguments? It would be 0 for >> zero arguments and abs for one argument. >> Allen, DaveH: If you pass one argument to hypot, you'll get NaN. >> Luke: It's not variadic. >> Waldemar: Why isn't it variadic? >> Luke: 2 or 3 is the 99% use case. >> Waldemar: 2 or 3 arguments is the 99% use case for max. >> Waldemar: If it's not variadic and takes only 2 or 3 arguments, >> you'll get silent mistakes. If you pass in four arguments, you'll get >> the hypot of the first three, and the last one will be silently >> ignored. That's bad. > I agree and it seems to be unadressed by the decision in the consensus, > is it? > If it's decided that hypot should only accept at most 3 arguments, then, > passing 4 or more args should return NaN (instead of making people hate > JavaScript more because of error hiding). > I however still believe having hypot variadic is more interesting, though.
All JavaScript built-ins accept and ignore unspecified extra arguments, so there is nothing out of the ordinary about ignoring a 4th augment. There is a significant difference between specifying that a function takes exactly 2 or 3 arguments and saying that it is takes an arbitrary number of arguments > >> Luke: Will go back to the experts to explore implementing variadic hypot. > Who/what does "the experts" refer to here? presumably Microsoft' keeps warehouses full of experts > > >> Note that the new function names such as hypot are generally selected >> to match the names from widely used c >> libraries: >> https://docs.google.com/spreadsheet/ccc?key=0Ak51JfLL8QLYdDBVcFZaMXhlY2d2RnM0TDVxLWlua3c&hl=en#gid=0 >> > I certainly missed the discussion where this choice was made, but does > C-matching matters? matching precedent. > For Math functions, I would tend to favor function names math folks are > used to, like the ones in Matlab (which I don't know at all, maybe they > map the C ones too). > > Is the proportion of people who come to JavaScript from C using math > libraries (as opposed to people coming to JavaScript with any other > background) big enough to consider familiarity with C function names a > decisive argument for JavaScript function naming? I believe that the thinking was that people may be translating Math libraries or numeric code currently implemented in C/C++ into JS and that name familiarity would help. Allen > > David > > [1] https://mail.mozilla.org/pipermail/es-discuss/2012-March/021919.html >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
