Augmenting Number.prototype with the functions from Math

Xavier MONTILLET xavierm02.net at gmail.com
Wed Jan 25 11:53:25 PST 2012


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


More information about the es-discuss mailing list