Le 13 janv. 2014 à 11:45, Anne van Kesteren ann...@annevk.nl a écrit :
In a discussion I had with Alex Russell as how to do comparison for
URL objects it ended up with desiring
url == url2
to work. It escaped me at that point that I already discussed this
briefly and Brendan explained
In the worst case, when I don't know if I have a string or an URLUtils
object, I just ensure that at least one member of the equality operator is
stringified—and, most importantly, that it is evident from reading my code
that one member is stringified:
a.href == url
I think there are cases where the intent of `==` can be clear such Point2D
or Point3D comparison, as well as generic collections.
In this case I am simulating though `hasSamecontentOf` method what I think
would be nice simplifying via `==`
```javascript
function Collection(entries) {
Hi Ben,
Sorry for the very late response.
This is quite an interesting work, thanks for sharing!
I'm particularly interested in your test suite [1] which is impressive.
This is making me realize that generators are fully compilable
(efficiently from what I can see) into ES5 and makes me wonder
for correctness sake, I forgot to check `this.every()` after a `this.length
=== collection.length this.every(...)`
On Tue, Jan 14, 2014 at 9:58 AM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
I think there are cases where the intent of `==` can be clear such Point2D
or Point3D
In JS world we are use to compare via === so that when == is used
instead we are usually in power user land, I don't see any conceptual
shenanigans in doing something like above code.
Only power users use == because it has weird conversion semantics that
are hard to internalize. == doesn't
Kevin Smith wrote:
Your point about it being too late to salvage == (vs. ===) is
good, but perhaps with value objects plus further work to disable
implicit conversions, == will make a come-back -- but that's far
down the road.
Work to disable implicit conversions? Can you
JavaScript is in a sticky place, it seems. `===` should mean strict equality
(modulo `-0`/`+0` and `NaN`, unfortunately), so just like `0 !== 0`, we want
`0 !== 0m`. That is, `===` won't be right for comparing numeric types, once we
have multiple numeric types.
However, `==` already means
== is overloadable along with and = to cope with unordered values and
to enable common safe comparisons, e.g. 0m == 0.
What does 0m === 0 mean?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
`0m` is literal syntax, for `decimal(0)`. Where `decimal` is a value type
factory.
http://www.slideshare.net/BrendanEich/web-futures/23
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
`0m` is literal syntax, for `decimal(0)`. Where `decimal` is a value type
factory.
Right - I meant what are the semantics of === applied to dissimilar,
perhaps numeric, value types.
___
es-discuss mailing list
es-discuss@mozilla.org
Kevin Smith wrote:
`0m` is literal syntax, for `decimal(0)`. Where `decimal` is a
value type factory.
Right - I meant what are the semantics of === applied to dissimilar,
perhaps numeric, value types.
We worked through this in 2008 when IBM was pushing decimal at ES3.1
(now ES5).
if you are not sure and you expect == to act like === within objects /
types then just use === and leave == for checks behind the typoef as
Brendan said.
Once again, let power users have the control they'd like to, specifications
should not prevent people from shooting their foot when/if they
While opinions vary, the fact remains that == and = are in the language,
are loose, and need to be overloadable for useful value objects,
specifically more numeric types.
I agree, that must be a goal of the design.
Suggest you pull == out of your mental penalty box and look at it again.
Kevin Smith wrote:
While opinions vary, the fact remains that == and = are in the
language, are loose, and need to be overloadable for useful value
objects, specifically more numeric types.
I agree, that must be a goal of the design.
Suggest you pull == out of your mental
So glad you asked, and you will like the answer:
js 0L == 0
typein:2:0 TypeError: no operator function found for ==
...and..I..do : )
http://goo.gl/N5txLJ
- The strict equality operators, === and !==, cannot be overloaded
- They work on frozen-by-definition value objects via a
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Brendan
Eich
js 0L == 0
typein:2:0 TypeError: no operator function found for ==
Hmm, upon seeing this in action, I'm not sure how I feel about `==` throwing.
It doesn't normally do that (modulo bad custom
Domenic Denicola wrote:
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Brendan
Eich
js 0L == 0
typein:2:0 TypeError: no operator function found for ==
Hmm, upon seeing this in action, I'm not sure how I feel about `==` throwing.
Oh for crying out loud!
half a
Heh, yes, damned if you do, etc. etc. I was trying to think up a practical
example where this would cause problems (e.g. in CSS libraries strings and
numbers often mix), but all my cases involved an `==`-using third party
library, in which case you'd just pass it `Number(myLong)` instead of
Domenic Denicola wrote:
Heh, yes, damned if you do, etc. etc. I was trying to think up a practical
example where this would cause problems (e.g. in CSS libraries strings and
numbers often mix), but all my cases involved an `==`-using third party
library, in which case you'd just pass it
I was thinking of
function thirdPartyLib(val) {
return val == 0;
}
thirdPartyLib(myLong); // exception
thirdPartyLib(Number(myLong)); // works
On Jan 14, 2014, at 22:50, Brendan Eich bren...@mozilla.com wrote:
Domenic Denicola wrote:
Heh, yes, damned if you do, etc. etc. I was trying to
That code deserves what it gets, good and hard. Including exceptions.
/be
On Jan 14, 2014, at 8:01 PM, Domenic Denicola wrote:
I was thinking of
function thirdPartyLib(val) {
return val =0;
}
thirdPartyLib(myLong); // exception
thirdPartyLib(Number(myLong)); // works
At risk of derailing the conversation with a tangent... I don't understand
the premise. Why is it so important that URLs are mutable? (Other than
already being drafted that way.)
We're seeing major performance and reliably improvements by going for more
immutable types in both our server and
23 matches
Mail list logo
