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 <[email protected]> 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 <[email protected]> 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 >>> [email protected] >>> https://mail.mozilla.org/listinfo/es-discuss >> >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss > > _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
