Augmenting Number.prototype with the functions from Math

Brendan Eich brendan at mozilla.org
Thu Jan 26 12:24:59 PST 2012


JS's Math namespace-object and its "methods" were modeled on JDK1.0 
java.lang.Math. This won't change. I see little benefit and too much 
cost relative to it in duplicating (with curried |this|) the functions 
into Number.prototype.

If there were a popular library that did this, it might help. Absent 
that, I think we should aim for bigger impact *with less duplication*, 
even in the smaller conveniences and affordances.

/be

> Xavier MONTILLET <mailto:xavierm02.net at gmail.com>
> January 26, 2012 12:04 PM
> Why would you write
>
> alert(2..pow(3)); // 8
>
> ?
>
> You would simply write 8 right away...
> But when you work with numbers, they're stored in variables and it works :
>
> var a = 2;
> a.pow( 3 );
>
> And anyway, you can still write
>
> (2).pow( 3 );
>
>
> And about the possibility to implement them in pure JS, you could say
> the same thing for maps. Still they're going to be added.
>
> On Thu, Jan 26, 2012 at 10:34 AM, Andrea Giammarchi
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
> Andrea Giammarchi <mailto:andrea.giammarchi at gmail.com>
> January 26, 2012 1:34 AM
> my point was: no need to have pow in Number.prototype, imo
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
> Allen Wirfs-Brock <mailto:allen at wirfs-brock.com>
> January 25, 2012 4:40 PM
>
> On Jan 25, 2012, at 3:47 PM, Andrea Giammarchi wrote:
>
>> Number.prototype.pow = function pow(radix) {
>>   return Math.pow(this, radix);
>> };
>>
>> //alert(2.pow(3)); // error, decimal point, not property accessor
>> alert(2..pow(3));  // 8
>> alert(NaN.pow(0)); // 1
>
> The last case is strictly in conformance with IEEE 754.  See 
> http://en.wikipedia.org/wiki/NaN#Quiet_NaN (and in particular, the 
> "Function definition" section) for an explanation.
>
> Allen
>
>
>>
>> until numbers are valid as digit. I don't see any advance on using 
>> Number.prototype for anything
>> until NaN is not instanceof Number but NaN.__proto__ is === 
>> Number.prototype, I don't see methods useful in the Number.prototype
>>
>> Last, but not least, I agree these are easy to implement through pure 
>> JS, no need to specs this stuff or make it native ( since after last 
>> 2 points I don't see common use cases in any case for polluted 
>> Number.prototype )
>>
>> my 2 cents,
>> br
>>
>> On Wed, Jan 25, 2012 at 8:53 PM, Xavier MONTILLET 
>> <xavierm02.net at gmail.com <mailto:xavierm02.net at gmail.com>> wrote:
>>
>>     About Object.method vs Object.prototype.method, I think it's
>>     something
>>     they adopted for *objects* because on objects, if you put these
>>     methods on the prototype, they might get shadowed. But since I'm
>>     talking about numbers, there is no such problem.
>>
>>     And I know I can make polyfills but I'd prefer to have it in the
>>     language itself because I'd be sure to have the same API in every
>>     environment and I wouldn't have to have a polyfill I have to include
>>     every single time. Plus I think this is generic enough to be part of
>>     core.
>>
>>     On Wed, Jan 25, 2012 at 8:36 PM, Jussi Kalliokoski
>>     <jussi.kalliokoski at gmail.com
>>     <mailto:jussi.kalliokoski at gmail.com>> wrote:
>>     > You can get emulate that kind of a feature quite simply in ES5+
>>     (and
>>     > earlier, if you have enough polyfills, or make compromises) if
>>     you like it,
>>     > see https://gist.github.com/1678065 .
>>     >
>>     > Cheers,
>>     > Jussi
>>     >
>>     >
>>     > On Wed, Jan 25, 2012 at 8:49 PM, Herby Vojčík <herby at mailbox.sk
>>     <mailto:herby at mailbox.sk>> wrote:
>>     >>
>>     >> I see more a "cultural" question here. There are lots of
>>     functions in ES
>>     >> which would make perfect (and probably better) sense if called
>>     on object
>>     >> than from outside (definePrototype & Co., maybe even isArray),
>>     but it is
>>     >> probably seen more "Javascriptic" to put them statically into
>>     Object,
>>     >> Number, Array, whatever.
>>     >>
>>     >> I think it has something with feeling they should not be
>>     dynamic part of
>>     >> object's contract, but on the contrary, they should be
>>     "decoupled" into safe
>>     >> managerial havens of Object, Array etc.
>>     >>
>>     >> But I can't say for sure.
>>     >>
>>     >> As I see it, in ES this is the way. Even if I don't like it,
>>     and it seems
>>     >> to me cumbersome to always do Object.fooBarBazAndMore(x, ...),
>>     I accept it
>>     >> as "Javascriptic" way to go.
>>     >>
>>     >> Moving just pow would create more confusion, I think. Moving
>>     more would
>>     >> also create lot of confusion (in actual state, only
>>     hasOwnProperty is the
>>     >> case which seems to not align with this way, being in
>>     Object.prototype; and
>>     >> you often see code like var hasOwn =
>>     Object.prototype.hasOwnProperty; or
>>     >> even var hasOwn =
>>     >> Function.prototype.call.bind(Object.prototype.hasOwnProperty)
>>     just to bring
>>     >> it back to "external actors" domain).
>>     >>
>>     >> Herby
>>     >>
>>     >>
>>     >> Xavier MONTILLET wrote:
>>     >>>
>>     >>> Hi,
>>     >>>
>>     >>> I think it'd be nice to have the functions available in Math in
>>     >>> Number.prototype.
>>     >>> e.g.
>>     >>>
>>     >>> Number.prototype.pow = function ( p ) {
>>     >>>     return Math.pow( this, p );
>>     >>> };
>>     >>>
>>     >>> Since pow is supposed to be an operator, I feel better when
>>     writing
>>     >>> a.pow( b ) than Math.pow( a, b );
>>     >>>
>>     >>> About the other methods, I'm not sure. They really are
>>     "functions" in
>>     >>> maths so it doesn't feel that weird calling them with Math.f( ).
>>     >>> Moreover if you store them in local variables.
>>     >>> But I still find doing a.abs( ).ceil( ) is way more
>>     convenient than
>>     >>> Math.ceil( Math.abs( a ) ).
>>     >>>
>>     >>> So since numbers are litterals and therefore extending the
>>     prototype
>>     >>> won't break anything, why not add it?
>>     >>> _______________________________________________
>>     >>> es-discuss mailing list
>>     >>> es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
>>     >>> https://mail.mozilla.org/listinfo/es-discuss
>>     >>
>>     >> _______________________________________________
>>     >> es-discuss mailing list
>>     >> es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
>>     >> https://mail.mozilla.org/listinfo/es-discuss
>>     >
>>     >
>>     _______________________________________________
>>     es-discuss mailing list
>>     es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
>>     https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
>> https://mail.mozilla.org/listinfo/es-discuss
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
> Andrea Giammarchi <mailto:andrea.giammarchi at gmail.com>
> January 25, 2012 3:47 PM
> Number.prototype.pow = function pow(radix) {
>   return Math.pow(this, radix);
> };
>
> //alert(2.pow(3)); // error, decimal point, not property accessor
> alert(2..pow(3));  // 8
> alert(NaN.pow(0)); // 1
>
> until numbers are valid as digit. I don't see any advance on using 
> Number.prototype for anything
> until NaN is not instanceof Number but NaN.__proto__ is === 
> Number.prototype, I don't see methods useful in the Number.prototype
>
> Last, but not least, I agree these are easy to implement through pure 
> JS, no need to specs this stuff or make it native ( since after last 2 
> points I don't see common use cases in any case for polluted 
> Number.prototype )
>
> my 2 cents,
> br
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
> Xavier MONTILLET <mailto:xavierm02.net at gmail.com>
> January 25, 2012 11:53 AM
> About Object.method vs Object.prototype.method, I think it's something
> they adopted for *objects* because on objects, if you put these
> methods on the prototype, they might get shadowed. But since I'm
> talking about numbers, there is no such problem.
>
> And I know I can make polyfills but I'd prefer to have it in the
> language itself because I'd be sure to have the same API in every
> environment and I wouldn't have to have a polyfill I have to include
> every single time. Plus I think this is generic enough to be part of
> core.
>
> On Wed, Jan 25, 2012 at 8:36 PM, Jussi Kalliokoski
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss


More information about the es-discuss mailing list