Xavier MONTILLET <mailto:[email protected]>
January 26, 2012 12:04 PM
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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
Andrea Giammarchi <mailto:[email protected]>
January 26, 2012 1:34 AM
my point was: no need to have pow in Number.prototype, imo
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
Allen Wirfs-Brock <mailto:[email protected]>
January 25, 2012 4:40 PM
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
<[email protected] <mailto:[email protected]>> 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
<[email protected]
<mailto:[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]
<mailto:[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] <mailto:[email protected]>
>>> https://mail.mozilla.org/listinfo/es-discuss
>>
>> _______________________________________________
>> es-discuss mailing list
>> [email protected] <mailto:[email protected]>
>> https://mail.mozilla.org/listinfo/es-discuss
>
>
_______________________________________________
es-discuss mailing list
[email protected] <mailto:[email protected]>
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected] <mailto:[email protected]>
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
Andrea Giammarchi <mailto:[email protected]>
January 25, 2012 3:47 PM
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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
Xavier MONTILLET <mailto:[email protected]>
January 25, 2012 11:53 AM
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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
