Re: Object.is()

2013-12-22 Thread Brendan Eich 

IMPORTANT TYPO ALERT!

Brendan Eich wrote:

No language stringifies -0 as "0"


I meant "-0".

that I know of. IIRC, IEEE-754 recommends against doing that. 
Stringizing is not for serialization, rather for human consumption in 
general, and -0 === 0. 


... jetlagged again, at least it is for vacation this time...

/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Object.is()

2013-12-22 Thread Brendan Eich 

Alex Kocharin wrote:

That's something I never really understood when I was reading ES5 spec, where-0 
 is a special case, and a sole reason why `x === Number(String(x))` is not true 
for all numbers.

Why isn't it stringified as "-0"? How did that happen? Do somebody really check if 
something is less than zero using "-" in string representation?
That goes back to ES1, not ES5, and probably to the ur-JS implementation 
(Mocha, in Netscape 2). And it arose due to same outcome in C sprintf, 
snprintf, etc.


No language stringifies -0 as "0" that I know of. IIRC, IEEE-754 
recommends against doing that. Stringizing is not for serialization, 
rather for human consumption in general, and -0 === 0.


/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Object.is()

2013-12-22 Thread Alex Kocharin 

23.12.2013, 05:59, "Brendan Eich" :
> Alex Kocharin wrote:
>
>>  Object.is() looks like a perfect function for checking oddballs (-0,
>>  NaN) if you want to represent an arbitrary data correctly. In that
>>  case distinguishing signed zeroes is a big plus
>
> or absolutely required.
>
>>  (making (-0).toString() === '-0' would be better though).
>
> (Not backward compatible -- no one is going to risk this for so little
> gain.)

That's something I never really understood when I was reading ES5 spec, where 
-0 is a special case, and a sole reason why `x === Number(String(x))` is not 
true for all numbers.

Why isn't it stringified as "-0"? How did that happen? Do somebody really check 
if something is less than zero using "-" in string representation?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Object.is()

2013-12-22 Thread Brendan Eich 

Mark S. Miller wrote:

Object.isz = (x, y) => x === y || Object.is(x, y);


Not bad.

/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Object.is()

2013-12-22 Thread Brendan Eich 

Alex Kocharin wrote:
Object.is() looks like a perfect function for checking oddballs (-0, 
NaN) if you want to represent an arbitrary data correctly. In that 
case distinguishing signed zeroes is a big plus


or absolutely required.


(making (-0).toString() === '-0' would be better though).


(Not backward compatible -- no one is going to risk this for so little 
gain.)


/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Object.is()

2013-12-22 Thread Till Schneidereit 
On Mon, Dec 23, 2013 at 1:11 AM, Rick Waldron wrote:

>
>
> On Sun, Dec 22, 2013 at 6:41 PM, Mark S. Miller wrote:
>
>> No, Map and Set will equate -0 and +0.
>>
>
> In SpiderMonkey's Set and Map:
>
>   var s = new Set([-0, +0]);
>   s.size; // 2
>
>   var m = new Map();
>   m.set(-0, 1);
>   m.set(+0, 2);
>
>   m.get(-0); // 1
>   m.get(+0); // 2
>

Filed bug [952870], patch included.

[952870]: https://bugzilla.mozilla.org/show_bug.cgi?id=952870
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Object.is()

2013-12-22 Thread Michał Gołębiowski 
Chrome Canary behaves similarly (with the difference that the Set
constructor can't convert an array), Olov reported an issue:
https://code.google.com/p/v8/issues/detail?id=3069

This is probably just code based on non-recent drafts as not equating
them would be bad for reasons Olov outlined in his post.

Why WeakMap/WeakSet continue differentiating between +0 and -0?

On Mon, Dec 23, 2013 at 1:11 AM, Rick Waldron  wrote:
>
>
>
> On Sun, Dec 22, 2013 at 6:41 PM, Mark S. Miller  wrote:
>>
>> No, Map and Set will equate -0 and +0.
>
>
> In SpiderMonkey's Set and Map:
>
>   var s = new Set([-0, +0]);
>   s.size; // 2
>
>   var m = new Map();
>   m.set(-0, 1);
>   m.set(+0, 2);
>
>   m.get(-0); // 1
>   m.get(+0); // 2
>
>
>
> Rick
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>



-- 
Michał Z. Gołębiowski
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Object.is()

2013-12-22 Thread Alex Kocharin 
 Object.is() looks like a perfect function for checking oddballs (-0, NaN) if you want to represent an arbitrary data correctly. In that case distinguishing signed zeroes is a big plus (making (-0).toString() === '-0' would be better though). I don't understand your use-case. If you just want to compare with NaN, Number.isNaN ain't going anywhere.  23.12.2013, 01:54, "Adam Ahmed" :If anecdotal sharing is valuable...As a JS web developer, I'd say so. I use isNaN weekly, and have never once had to distinguish +/-0. It may be useful in some very limited cases, but for me Object.is would be much more valuable without it. Having the distinction means that in most cases I won't be able to use Object.is because I want +0 to equal -0.On 23/12/2013 8:39 AM, "Axel Rauschmayer"  wrote:We talked about this at the last last TC39 meeting. I joked about adding Object.isz, or (in honor of @izs) Object.izs. ;-)But we didn't add anything. You can write it yourself, of course (just modify the Object.is polyfill). My question … is: Wouldn’t `Object.is()` be more useful if it didn’t distinguish +0 and -0?-- Dr. Axel Rauschmayera...@rauschma.de home: rauschma.detwitter: twitter.com/rauschmablog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ,___es-discuss mailing listes-discuss@mozilla.orghttps://mail.mozilla.org/listinfo/es-discuss___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Object.is()

2013-12-22 Thread Rick Waldron 
On Sun, Dec 22, 2013 at 6:41 PM, Mark S. Miller  wrote:

> No, Map and Set will equate -0 and +0.
>

In SpiderMonkey's Set and Map:

  var s = new Set([-0, +0]);
  s.size; // 2

  var m = new Map();
  m.set(-0, 1);
  m.set(+0, 2);

  m.get(-0); // 1
  m.get(+0); // 2



Rick
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: getOwnPropertySymbols + getOwnPropertyNames

2013-12-22 Thread Andrea Giammarchi 
I hope in addiction, since at least getOwnPropertyNames is slightly
polyfillable ... having only a method that exposes both makes migration
more painful, imho


On Sun, Dec 22, 2013 at 7:52 AM, Axel Rauschmayer  wrote:

>
> https://github.com/rwaldron/tc39-notes/blob/master/es6/2013-09/sept-18.md#consensusresolution-1
>
> Honest question: Is there any use case where you would *not* want to
> iterate over both?
>
> If yes then I’d prefer to have getOwnPropertyKeys (in addition or instead
> of getOwnPropertySymbols).
>
> Axel
>
> --
> Dr. Axel Rauschmayer
> a...@rauschma.de
>
> home: rauschma.de
> twitter: twitter.com/rauschma
> blog: 2ality.com
>
>
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Object.is()

2013-12-22 Thread Olov Lassus 
2013/12/23 Mark S. Miller 

> No, Map and Set will equate -0 and +0.
>

\o/

Filed a bug on v8: https://code.google.com/p/v8/issues/detail?id=3069
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Object.is()

2013-12-22 Thread Mark S. Miller 
On Sun, Dec 22, 2013 at 3:28 PM, Brendan Eich  wrote:

> Domenic Denicola wrote:
>
>> If the belief is truly that SameValueZero is more useful than SameValue,
>> perhaps we should consider relaxing that restriction, and allowing people
>> to flip the sign of non-writable zero-valued properties?
>>
>
> You are reasoning from general to particular, but without any reason to
> focus on the particular of redefining a non-writable property from -0 to +0
> or vice versa. There is no use-case "there" there! I bet Mark would find
> that a subtle security problem.


Yes, it opens an overt communications channel through allegedly frozen
state.


>
>
>Indeed, perhaps it would be worth trying to move some of the strict
>> equality comparisons over to SameValueZero, if that doesn't break too many
>> things.
>>
>
> Who knows? 1JS and browser game theory combine to mean no one will risk
> trying, only to lose compatibility around the edges.
>
>
>I know moving to SameValue has been discussed and rejected in the past,
>> but that was before SameValueZero was baked into the spec.
>>
>
> No one is discussing changing === and !==, AFAIK. Not every, in TC39.
>
>
>  (I personally dislike the existence of SameValueZero, and would rather
>> stick with SameValue. But I have no reasonable arguments from practicality,
>> only theoretical purity, and so I don't anticipate convincing anyone.)
>>
>
> We should look at this again. The newest thing is the one to cast a colder
> eye at.
>
> /be
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>



-- 
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Object.is()

2013-12-22 Thread Mark S. Miller 
No, Map and Set will equate -0 and +0.


On Sun, Dec 22, 2013 at 3:38 PM, Olov Lassus  wrote:

> 2013/12/23 Brendan Eich 
>
>> You are reasoning from general to particular, but without any reason to
>> focus on the particular of redefining a non-writable property from -0 to +0
>> or vice versa. There is no use-case "there" there! I bet Mark would find
>> that a subtle security problem.
>>
>
> On the topic of +0, -0 and use cases... Is it still intended that Map and
> Set will distinguish between these two values? I'm not sure what the use
> case would be but I fear the consequences. Further elaborated in <
> https://mail.mozilla.org/pipermail/es-discuss/2012-December/026794.html>.
>
> /Olov
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>


-- 
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Object.is()

2013-12-22 Thread Olov Lassus 
2013/12/23 Brendan Eich 

> You are reasoning from general to particular, but without any reason to
> focus on the particular of redefining a non-writable property from -0 to +0
> or vice versa. There is no use-case "there" there! I bet Mark would find
> that a subtle security problem.
>

On the topic of +0, -0 and use cases... Is it still intended that Map and
Set will distinguish between these two values? I'm not sure what the use
case would be but I fear the consequences. Further elaborated in <
https://mail.mozilla.org/pipermail/es-discuss/2012-December/026794.html>.

/Olov
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: Object.is()

2013-12-22 Thread Domenic Denicola 
From: Brendan Eich [mailto:bren...@mozilla.com] 

> No one is discussing changing === and !==, AFAIK. Not every, in TC39.

To clarify, I was talking about previous discussions where (IIRC) some hoped to 
move `Array.prototype.indexOf` to SameValue. Those were abandoned for 
compatibility reasons, but I was wondering if it would be possible to move 
`indexOf` (and `case` matching, perhaps) to SameValueZero. Sounds like 
"probably no," in any case.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Object.is()

2013-12-22 Thread Mark S. Miller 
Object.isz = (x, y) => x === y || Object.is(x, y);



On Sun, Dec 22, 2013 at 3:28 PM, Brendan Eich  wrote:

> Domenic Denicola wrote:
>
>> If the belief is truly that SameValueZero is more useful than SameValue,
>> perhaps we should consider relaxing that restriction, and allowing people
>> to flip the sign of non-writable zero-valued properties?
>>
>
> You are reasoning from general to particular, but without any reason to
> focus on the particular of redefining a non-writable property from -0 to +0
> or vice versa. There is no use-case "there" there! I bet Mark would find
> that a subtle security problem.
>
>
>Indeed, perhaps it would be worth trying to move some of the strict
>> equality comparisons over to SameValueZero, if that doesn't break too many
>> things.
>>
>
> Who knows? 1JS and browser game theory combine to mean no one will risk
> trying, only to lose compatibility around the edges.
>
>
>I know moving to SameValue has been discussed and rejected in the past,
>> but that was before SameValueZero was baked into the spec.
>>
>
> No one is discussing changing === and !==, AFAIK. Not every, in TC39.
>
>
>  (I personally dislike the existence of SameValueZero, and would rather
>> stick with SameValue. But I have no reasonable arguments from practicality,
>> only theoretical purity, and so I don't anticipate convincing anyone.)
>>
>
> We should look at this again. The newest thing is the one to cast a colder
> eye at.
>
> /be
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>



-- 
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Object.is()

2013-12-22 Thread Brendan Eich 

Domenic Denicola wrote:

If the belief is truly that SameValueZero is more useful than SameValue, 
perhaps we should consider relaxing that restriction, and allowing people to 
flip the sign of non-writable zero-valued properties?


You are reasoning from general to particular, but without any reason to 
focus on the particular of redefining a non-writable property from -0 to 
+0 or vice versa. There is no use-case "there" there! I bet Mark would 
find that a subtle security problem.



  Indeed, perhaps it would be worth trying to move some of the strict equality 
comparisons over to SameValueZero, if that doesn't break too many things.


Who knows? 1JS and browser game theory combine to mean no one will risk 
trying, only to lose compatibility around the edges.



  I know moving to SameValue has been discussed and rejected in the past, but 
that was before SameValueZero was baked into the spec.


No one is discussing changing === and !==, AFAIK. Not every, in TC39.


(I personally dislike the existence of SameValueZero, and would rather stick 
with SameValue. But I have no reasonable arguments from practicality, only 
theoretical purity, and so I don't anticipate convincing anyone.)


We should look at this again. The newest thing is the one to cast a 
colder eye at.


/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: Object.is()

2013-12-22 Thread Domenic Denicola 
If the thought is that distinguishing +0 and -0 is never useful, then the goal 
should be to stop distinguishing between them wherever possible.

Currently there are three "strict-ish" equality tests: Strict Equality 
Comparison (`===`), SameValueZero, and SameValue (`Object.is`). We'll leave 
Abstract Equality Comparison (`==`) out of this.

- Strict Equality Comparison is used in `case` matching, 
`Array.prototype.indexOf`, `Array.prototype.lastIndexOf`, and `===`.
- SameValueZero is used for `Map`s and `Set`s, plus something about 
`ArrayBuffer` lengths.
- SameValue is used in many places throughout the spec, especially relating to 
property values; it is also used for `WeakMap`s and `WeakSet`s.

Note that most of the uses of SameValue are cases where the input is already 
guaranteed to be either an object (e.g. prototypes, property descriptor `set` 
functions) or a string (property keys). So many of them could be replaced with 
SameValueZero, or even Strict Equality Comparison, without consequence.

But there are a few cases, e.g. property redefinition, that do distinguish. For 
example, if you have a non-writable/non-configurable property whose value is 
-0, then trying to set/redefine that property will fail, since SameValue is 
used in that test.

If the belief is truly that SameValueZero is more useful than SameValue, 
perhaps we should consider relaxing that restriction, and allowing people to 
flip the sign of non-writable zero-valued properties? Indeed, perhaps it would 
be worth trying to move some of the strict equality comparisons over to 
SameValueZero, if that doesn't break too many things. I know moving to 
SameValue has been discussed and rejected in the past, but that was before 
SameValueZero was baked into the spec.

(I personally dislike the existence of SameValueZero, and would rather stick 
with SameValue. But I have no reasonable arguments from practicality, only 
theoretical purity, and so I don't anticipate convincing anyone.)
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Object.is()

2013-12-22 Thread Adam Ahmed 
If anecdotal sharing is valuable...

As a JS web developer, I'd say so. I use isNaN weekly, and have never once
had to distinguish +/-0. It may be useful in some very limited cases, but
for me Object.is would be much more valuable without it. Having the
distinction means that in most cases I won't be able to use Object.is
because I want +0 to equal -0.
 On 23/12/2013 8:39 AM, "Axel Rauschmayer"  wrote:

> We talked about this at the last last TC39 meeting. I joked about adding
> Object.isz, or (in honor of @izs) Object.izs.
>
>
> ;-)
>
> But we didn't add anything. You can write it yourself, of course (just
> modify the Object.is polyfill).
>
>
> My question … is: Wouldn’t `Object.is()` be more useful if it didn’t
> distinguish +0 and -0?
>
> --
> Dr. Axel Rauschmayer
> a...@rauschma.de
>
> home: rauschma.de
> twitter: twitter.com/rauschma
> blog: 2ality.com
>
>
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Object.is()

2013-12-22 Thread Axel Rauschmayer 
> We talked about this at the last last TC39 meeting. I joked about adding 
> Object.isz, or (in honor of @izs) Object.izs.

;-)

> But we didn't add anything. You can write it yourself, of course (just modify 
> the Object.is polyfill).

My question … is: Wouldn’t `Object.is()` be more useful if it didn’t 
distinguish +0 and -0?

-- 
Dr. Axel Rauschmayer
a...@rauschma.de

home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com



___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Object.is()

2013-12-22 Thread Brendan Eich 
We talked about this at the last last TC39 meeting. I joked about adding 
Object.isz, or (in honor of @izs) Object.izs. But we didn't add 
anything. You can write it yourself, of course (just modify the 
Object.is polyfill).


/be


Axel Rauschmayer 
December 22, 2013 1:00 AM
The use case for `Object.is ()` that I see is to 
have a version of `===`, as a function, that allows one to 
detect/search for `NaN`. For that use case, distinguishing +0 and -0 
seems problematic (they are equated almost everywhere else). Should 
they really be distinguished by `Object.is ()`?


Axel

--
Dr. Axel Rauschmayer
a...@rauschma.de 

home: rauschma.de 
twitter: twitter.com/rauschma 
blog: 2ality.com 



___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Symbol.keyFor

2013-12-22 Thread Kevin Smith 
>
>
>> "Name" is good.
>>
>> Symbol.name(Symbol.for("foo")) === "foo";
>>
>> Or some variant thereof.
>>
>
> I like this, but it interferes with the name property that all function
> objects have—the Symbol.name property would no longer have the expected
> value "Symbol".
>
>
Oh yes - doh!  : )
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Symbol.keyFor

2013-12-22 Thread Rick Waldron 
On Sun, Dec 22, 2013 at 10:18 AM, Kevin Smith  wrote:

> In KeyKOS we used the word "name". We had another meaning for the word
>> "key" and wanted to avoid confusion.
>
>
> "Name" is good.
>
> Symbol.name(Symbol.for("foo")) === "foo";
>
> Or some variant thereof.
>

I like this, but it interferes with the name property that all function
objects have—the Symbol.name property would no longer have the expected
value "Symbol".

Rick
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

getOwnPropertySymbols + getOwnPropertyNames

2013-12-22 Thread Axel Rauschmayer 
https://github.com/rwaldron/tc39-notes/blob/master/es6/2013-09/sept-18.md#consensusresolution-1

Honest question: Is there any use case where you would *not* want to iterate 
over both?

If yes then I’d prefer to have getOwnPropertyKeys (in addition or instead of 
getOwnPropertySymbols).

Axel

-- 
Dr. Axel Rauschmayer
a...@rauschma.de

home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com



___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Symbol.keyFor

2013-12-22 Thread Kevin Smith 
>
> In KeyKOS we used the word "name". We had another meaning for the word
> "key" and wanted to avoid confusion.


"Name" is good.

Symbol.name(Symbol.for("foo")) === "foo";

Or some variant thereof.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Symbol.keyFor

2013-12-22 Thread Bill Frantz 
In KeyKOS we used the word "name". We had another meaning for 
the word "key" and wanted to avoid confusion.


Cheers - Bill

On 12/22/13 at 9:57 PM, a...@rauschma.de (Axel Rauschmayer) wrote:


Offhand, ID instead of key, but that is awfully generic. It may make sense to 
invent a new term.

On Dec 22, 2013, at 6:53 , Mark S. Miller  wrote:


Suggestions?


On Sat, Dec 21, 2013 at 9:48 PM, Axel Rauschmayer  wrote:
One problem with that method name: it overloads the term “key”. At the moment, 
property keys are either

strings or symbols. If a symbol can also have a key, I’d find that confusing.


Axel

--
Dr. Axel Rauschmayer
a...@rauschma.de

home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com

--
Cheers,
--MarkM



---
Bill Frantz| "I wish there was a knob on the TV to turn 
up the
408-356-8506   | intelligence.  There's a knob called 
"brightness", but

www.pwpconsult.com | it doesn't work. -- Gallagher

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss