Actually I wrote pretty much the similar one with less functions (since I
haven't need to use them yet), but with different name (I use Stream, since my
idea are simply from Java 8's Stream AI)
yep, I'm afraid this is described as such in the old post (and in specs)
too:
Return true if x and y refer to the same object. Otherwise, return false
in your Point cases you can add `.equals(otherPoint)` in Point prototype
otherwise use an utility that does similar thing Java does.
Regards
Andrea Giammarchi wrote:
A generic description-aware `Reflect.describe(genericObject)`like
approach seems way more useful for logging annd debugging purpose than
a footgun in the wild.
Good idea, should find an ES7 champion. If we had this, I think we could
have made String(sym) throw, and
Le 4 janv. 2015 à 00:44, Caitlin Potter caitpotte...@gmail.com a écrit :
I agree on that point, and therefore I didn't make any refactoring argument.
I was referring specifically to C12 (and one other, IIRC) on bug 3477
(For reference, bug 3477 C12 is here:
Hi, please add me to the list members
The best regards, Alexander
https://github.com/monolithed
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Le 4 janv. 2015 à 03:18, Rick Waldron waldron.r...@gmail.com a écrit :
On Sat Jan 03 2015 at 8:25:40 PM Brendan Eich bren...@mozilla.org wrote:
Rick Waldron wrote:
That example above is pretty compelling for throw always consistency.
With a new Reflect.* API for converting a symbol
I think it’s great that maps and sets honor insertion order.
Two ideas:
* Sets: Could the keys used for `Set.prototype.entries()` and
`Set.prototype.forEach()` be the position of an element? IMO that’d be more
useful than using the element as both key and value.
* Maps: Long-term, I’d love to
Alex Kocharin wrote:
My point is: concatenating Symbols with other strings have
legitimate
uses.
Name one.
I did name one in another message. Logging.
That's a use-case for some way (could be concatenation, but as noted the
downside risk is huge; could be a new Reflect
Alex, like I've said:
`log({__proto__:null})` and welcome crashes of the server, if that's a real
concern in this form.
Is it that wrong to assume that if `console.log({__proto__:null})` is
capable of handling non Objects and print a meaningful output, so should
any other logger implemented on
Claude Pache wrote:
Now, it will be argued that it would be a precedent to make such a distinction
between implicit and explicit coercion, for, until ES5, there is none.
Kind of there all along, as noted up-thread:
js o = {valueOf(){return 42}, toString(){return 'haha'}}
({valueOf:function
Forgot to retitle it.
On Jan 3, 2015 9:44 PM, Isiah Meadows impinb...@gmail.com wrote:
From: Axel Rauschmayer a...@rauschma.de
To: bren...@mozilla.org
Cc: es-discuss list es-discuss@mozilla.org
Date: Sun, 4 Jan 2015 03:17:54 +0100
Subject: Re: Implicit coercion of Symbols
Does it have
From: monolithed monolit...@gmail.com
To: es-discuss@mozilla.org
Cc:
Date: Sun, 4 Jan 2015 19:28:28 +0400
Subject: Add to the list members
Hi, please add me to the list members
The best regards, Alexander
https://github.com/monolithed
Here's you a link:
I agree that use equals is a better choice. If operator overloading is
implemented, you may experience inconsistency (different instance of builtin
boxed values would be unequal according to default semantics, while after
overloaded == operator it becomes equal.)
Date: Sat, 3 Jan 2015 23:52:58
In Section B.3.1 on __proto__ Property Names in Object Initializers
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-__proto__-property-names-in-object-initializers
there is a paragraph explaining when duplicate properties will result in a
syntax error. It says:
It is a Syntax Error if
On Jan 4, 2015 9:06 PM, Fred Schott fksch...@gmail.com wrote:
In Section B.3.1 on __proto__ Property Names in Object Initializers there
is a paragraph explaining when duplicate properties will result in a syntax
error. It says:
It is a Syntax Error if PropertyNameList of
From: Fred Schott fksch...@gmail.com
To: es-discuss@mozilla.org
Cc:
Date: Sun, 4 Jan 2015 23:06:56 -0600
Subject: Question regarding duplicate computed __proto__ properties
In Section B.3.1 on __proto__ Property Names in Object Initializers there
is a paragraph explaining when duplicate
I agree that use equals is a better choice. If operator overloading is
implemented, you may experience inconsistency (different instance of builtin
boxed values would be unequal according to default semantics, while after
overloaded == operator it becomes equal.)
Date: Sat, 3 Jan 2015 23:52:58
Filed as Bug 3510. Thanks for the confirmation, Allen.
—
Sent from Mailbox
On Sun, Jan 4, 2015 at 9:13 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Jan 4, 2015 9:06 PM, Fred Schott fksch...@gmail.com wrote:
In Section B.3.1 on __proto__ Property Names in Object Initializers there
18 matches
Mail list logo
