Augmenting Number.prototype with the functions from Math

Andrea Giammarchi andrea.giammarchi at gmail.com
Thu Jan 26 01:34:54 PST 2012


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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120126/2d5e1e8e/attachment.html>


More information about the es-discuss mailing list