Discuss
  • Augmenting Number.prototype with the functions from Math

Augmenting Number.prototype with the functions from Math

# Xavier MONTILLET (14 years ago)

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?

# Herby Vojčík (14 years ago)

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

# Jussi Kalliokoski (14 years ago)

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 gist.github.com/1678065 .

# Xavier MONTILLET (14 years ago)

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.

# Andrea Giammarchi (14 years ago)

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

# Allen Wirfs-Brock (14 years ago)

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 en.wikipedia.org/wiki/NaN#Quiet_NaN (and in particular, the "Function definition" section) for an explanation.

# Andrea Giammarchi (14 years ago)

my point was: no need to have pow in Number.prototype, imo

# Xavier MONTILLET (14 years ago)

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.

# Brendan Eich (14 years ago)

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.