Le 16/08/2012 04:40, Allen Wirfs-Brock a écrit :
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.
If authors can be confused into thinking the function legitimately
accepts 4 arguments while it only takes 2 or 3, it seems out of the
ordinary.
parseInt ignores its third argument, but there is no obvious third
argument to pass anyway.
Math.max ignores no argument and legitimately so.
hypot ignores all arguments beyond the third for no good reason.
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
I agree, but I don't understand what you mean here. Is it an argument
against the idea of defining a function that takes an arbitrary number
of arguments? It's been done with Math.max and quite successfully so as
far as I know.
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.
Ok, but I think my question still stands. People may also be translating
Math libs from Matlab or any other math-oriented language. Why favoring
C against Matlab folks?
David
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
