Augmenting Number.prototype with the functions from Math

Xavier MONTILLET xavierm02.net at gmail.com
Thu Jan 26 12:04:19 PST 2012


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
<andrea.giammarchi at gmail.com> wrote:
> my point was: no need to have pow in Number.prototype, imo
>
>
> On Thu, Jan 26, 2012 at 1:40 AM, Allen Wirfs-Brock <allen at wirfs-brock.com>
> wrote:
>>
>>
>> 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> 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> 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> 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
>>> >>> https://mail.mozilla.org/listinfo/es-discuss
>>> >>
>>> >> _______________________________________________
>>> >> es-discuss mailing list
>>> >> 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
>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>


More information about the es-discuss mailing list