Feedback on hypot and hypot2

David Bruant bruant.d at
Thu Aug 16 00:53:40 PDT 2012

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 
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?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list