Feedback on hypot and hypot2

Allen Wirfs-Brock allen at
Wed Aug 15 19:40:46 PDT 2012

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:
> 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.


> David
> [1]

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

More information about the es-discuss mailing list