Re: @@toStringTag spoofing for null and undefined

This is indeed a change from ES5. Has any major engine or other test-vehicle tried to see how web-compatible it is? /be Caitlin Potter wrote: I believe making String non-exotic has been discussed, and if this has changed from ES5, it could be related to that.

Re: Property names for public symbols

Mark Volkmann wrote: I'm curious why one of the public symbols has a name that ends with "Tag" ("toStringTag"), but the others don't (such as "toPrimitive"). Maybe "toStringTag" should be changed to "toString". That would be the wrong name -- the Tag is specific, particular to the purpose of

Re: Property names for public symbols

Axel Rauschmayer wrote: Can you explain what you mean by “same-named”? You want `Symbol.for()` to have the same casing as `Symbol.iterator`? No, I mean we would normally use iterator (and had __iterator__ in SpiderMonkey, then '@@iterator' I believe), not ITERATOR. Python's dunder-bracketing

Re: Property names for public symbols

Some tasteful inconsistency (the hobgoblin of big minds) is required here. We want the well known symbols' names as static properties of Symbol to be same-named. /be Mark Volkmann wrote: Agreed, like at the constants on the Math object. --- R. Mark Volkmann Object Computing, Inc. On Feb 6,

Re: Set and Map iteration order

Benjamin (Inglor) Gruenbaum wrote: We don't all have superpowers and know how to find targeted topics from 3 years ago :) (I did google search, I'll work on my list search-fu) This one didn't require my elephantine memory :-P. https://www.google.com/webhp?q=site:esdiscuss.org+%22set+iteratio

Re: Set and Map iteration order

https://esdiscuss.org/topic/set-iterators (site: search again, but I admit I used deterministic and tyler close keywords to help.) /be Benjamin (Inglor) Gruenbaum wrote: Hi, I recently answered a question on StackOverflow about set iteration order which made me read the spec. I remember th

Re: Aborting an async function

Benjamin (Inglor) Gruenbaum wrote: Cancellation of promises is something that has been debated several times (not sure if at all in esdiscuss). Many times: https://www.google.com/search?q=site%3Aesdiscuss.org%20cancel%20promise Google site: search is your friend. /be ___

Re: Rev32 ES6 draft now available

Allen Wirfs-Brock wrote: Changes include: * Removed ‘new super()’ syntax * new.target meta-property no longer highlighted as tentative. * Methods defined within class definitions are now non-enumerable * Classes defined as class extends null {...} are now consider to be

Re: Informative notes

Benjamin (Inglor) Gruenbaum wrote: For example - I don't need to know or understand what `[[ReferenceGet]]` is to understand something written in this sort of style: https://wiki.php.net/rfc/combined-comparison-operator Not bad -- we are using gists and github markdown but could build that up

Re: The history about VariableStatement

Felix Kling wrote: That made me wonder why /VariableStatement/ was a /Statement/ to begin with? Maybe the concept of a "declaration" wasn't really developed back then, but then what was the reasoning for /FunctionDeclaration/ not being a /Statement/ (was it even part of ES1? I don't know) ?

Re: The history about VariableStatement

Mark S. Miller wrote: On Mon, Feb 2, 2015 at 8:21 AM, Felix Kling > wrote: With ES6 having a production rule "Declaration" and ES5 having "FunctionDeclaration", I'm curious why a variable declaration (as we say), officially "VariableStatement", has not bee

Re: The enumerate trap and Object.create()

Good catch! I think this old decision pre-dates for-of. Cc'ing Tom. Leon, could you please cite the bug in a followup here if you file it? Thanks, /be Allen Wirfs-Brock wrote: Thanks, Please file a bug on this at bug.ecmascript.org AllenOn Jan 30, 2015 8:41 PM, Leon Arnott wrote: Lately I

Re: classes and enumerability

Andrea Giammarchi wrote: Do we agree this class decision was a good one? Perfect, then let's move on to another thread and discuss how things could be better from "both worlds" point of view in the future. I'm not sure why you replied to me, since I (and everyone on TC39) has agreed to make t

Re: classes and enumerability

Brendan Eich wrote: Please drop the crappy "us" vs. "them" talk. If you read this thread, and others on esdiscuss.org, you can see "TC39" did not "keep ignoring feedback". Yeesh! In case it is not clear: Andrea is not on TC39, not "us"

Re: classes and enumerability

Please drop the crappy "us" vs. "them" talk. If you read this thread, and others on esdiscuss.org, you can see "TC39" did not "keep ignoring feedback". Yeesh! We (TC39 includes web developers, W3C TAG members, WHATWG members and cofounders, all well-connected to others working with and on WebI

Re: export default and export {foo as default}?

I recall others being confused; probably an informative note in the spec would help. /be Erik Arvidsson wrote: I looked into it in more details and I seem to have been mistaken. "*default*" is just internal spec name that is needed for hoisting FunctionDeclaration and to create the required a

Re: classes and enumerability

Boris Zbarsky wrote: On 1/29/15 2:55 PM, Brendan Eich wrote: Announcement: ES6 class method syntax makes a non-enumerable property of the method's name on the class prototype. That is all. :-) Please post to public-script-coord with the proposed plan for web idl. I was hoping someone d

Re: classes and enumerability

Announcement: ES6 class method syntax makes a non-enumerable property of the method's name on the class prototype. That is all. :-) /be Brendan Eich wrote: Herby Vojčík wrote: Personally, I have always believed we are going down the wrong path by switching (from the original max-in

Re: Figuring out the behavior of WindowProxy in the face of non-configurable properties

Mark S. Miller wrote: Exactly correct. I didn't realize until reading your reply is that this is all that's necessary -- that it successfully covers all the cases I was thinking about without any further case division. Here's another option, not clearly better or worse: [[D

Re: Figuring out the behavior of WindowProxy in the face of non-configurable properties

Mark S. Miller wrote: The reason why the intent is unwarranted is that the descriptor omits "configurable:" rather than explicitly saying "configurable: true". If the owner object already has a configurable own property of the same name, then a defineProperty where the "configurable:" is omitte

Re: Question about Symbols and GlobalSymbolRegistry

Axel Rauschmayer wrote: So there's no need for this There is one use case (admittedly a rather hypothetical one): serializing the Symbol.* symbols to a text format (e.g. an encoding in JSON). Symbols that user-code puts into the registry do not serialize this way, so why should the well-kn

Re: Question about Symbols and GlobalSymbolRegistry

Axel Rauschmayer wrote: It may make sense to add them. Their identifiers would have to be as unambiguous as possible, e.g. URIs such as "http://ecmascript.org/symbol/foo";. Symbol.iterator and the other well-known symbols are self-same in all connected realms. See http://people.mozilla.org/~

Re: JavaScript 2015?

Allen Wirfs-Brock wrote: I can only speak about ES5 (don't know about ES1,2,3 but a I'm pretty sure there wasn't a year long bake period before each of those). Nope. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/lis

Re: JavaScript 2015?

Aaron Frost wrote: Trying to understand the cadenced release process. In the past a Final Draft would be cut and allowed to bake for 12 months before an Official Approval by the Ecma General Assembly. Is that 12-month bake still going to be in place? More like six months, really -- Allen can

Re: classes and enumerability

Herby Vojčík wrote: Personally, I have always believed we are going down the wrong path by switching (from the original max-in class design) to making methods defined within a class definition enumerable. Yes, please, if possible, go back to non-enum methods. I was writing at that time as well

Re: JavaScript 2015?

Andrea Giammarchi wrote: I've heard the "delivery, delivery, delivery" story before and I haven't seen a single case where that translated into more quality as outcome. You make it sound like quantity goes up, or at least exceeds what can be "QA'ed" by implementors and developers before being

Re: JavaScript 2015?

Allen Wirfs-Brock wrote: And highly visible to anybody who looks at the front cover: http://wiki.ecmascript.org/lib/exe/fetch.php?id=harmony%3Aspecification_drafts&cache=cache&media=harmony:working_draft_ecma-262_edition_6_01-15-15.pdf

Re: JavaScript 2015?

Domenic Denicola wrote: I believe the cutover was decided in the September 25 meeting. I must have missed it if so -- do the notes record it? As Andreas Rossberg points out, ES6 will take years to be fully implemented. The more we speculate (lay bets), the bigger our potential losses. At t

Re: JavaScript 2015?

ng ES6 now would be renaming it later, though. On 23 Jan 2015, at 01:44, Arthur Stolyar mailto:nekr.fab...@gmail.com>> wrote: Can we leave ES6 to ES6 because it's already here and call ES7 -- ES2016? Since ES7 not here yet and there are not much mentions of it. 2015-01-

Re: JavaScript 2015?

I wouldn't hold my breath. Sun was not ever in the mood, even when I checked while at Mozilla just before the Oracle acquisition closed. Also, "the community" cannot own a trademark. Trademarks must be defended, or you lose them. This arguably has happened to JavaScript. Perhaps the best cours

Re: JavaScript 2015?

quot;, as cited below. /be On Fri, Jan 23, 2015 at 12:39 AM, Brendan Eich <mailto:bren...@mozilla.org>> wrote: ... This reminds me: Axel (not Alex) cannot recommend "JavaScript 2015" to anything near the Ecma standard, because trademark. :-/

Re: non-strict direct eval in top level scope

Firefox's engine has an ES4-era prototype `let` implementation, a bug to fix by implementing ES6 semantics. https://bugzilla.mozilla.org/show_bug.cgi?id=950547 /be Francisco Tolmasky wrote: Apologies as I believe this has been discussed before ( https://esdiscuss.org/topic/block-scope-direct-

Re: JavaScript 2015?

Andrea Giammarchi wrote: I particularly don't like the idea that things could be dropped or rushed last minute just because the new years eve is coming ... this feel like those stories with tight deadlines where management could easily fail due over-expectations on all possible 3rd parts alignm

Re: JavaScript 2015?

Andrea Giammarchi wrote: I really don't understand ... I'm pretty sure you do understand -- you just don't like it. The annual cycle may fail, but that would be "bad". If it works out, we could still continue with ES6, 7, 8, etc. I'm leery of revolutionary fanaticism of the kind that led th

Re: JavaScript 2015?

Brendan Eich wrote: The reason to label editions or releases is not to give marketeers some brand suffix with which to tout or hype. It's to organize a series of reasonably debugged specs that implementors have vetted and (partly or mostly) implemented. I agree it would be best if (part

Re: JavaScript 2015?

Andrea Giammarchi wrote: agreed and not only, it took years before various engines fully implemented ES5 so saying years later that an engine is fully compliant with a year in the past feels so wrong !!! Why is that? Where is the thread that explains this decision? I mean ... how should I cal

Re: JavaScript 2015?

"Harmony" refers to the whole post-ES4 consensus-based arc of specs from ES5 (neé 3.1) onward into the future, until "done" ;-). See https://mail.mozilla.org/pipermail/es-discuss/2008-August/006837.html ECMAScript Harmony never referred to a specific edition of ECMA-262, nor could it. The "Har

Re: @@toStringTag spoofing for null and undefined

and check is so problematic. It is based upon and supports the misperception that such a branded object will have all of the specified initial characteristics of the correspond built-in. This is a great point, which makes me want to +1 your suggestion: Allen Wirfs-Brock wrote: On Jan 21, 2

Re: Clarification regarding "top level" arrow functions and "this"/"arguments"

ECMA-357 (E4X) pioneered informative-first prose sections, not found in ECMA-262 Ed. 3, and as a direct consequence, had too many imprecise or even inaccurate informative notes, which (turns out) were misread as normative, or simply otherwise caused confusion. Thanks for looking into fixing th

Re: @@toStringTag spoofing for null and undefined

Brendan Eich wrote: Sure -- good point, I flinched and was slot "slow", lulz. /be to say "internal property" because we all don't like infernal slots. ;-) ___ es-discuss mailing list es-discuss@mozilla.org https://mai

Re: @@toStringTag spoofing for null and undefined

Allen Wirfs-Brock wrote: On Jan 21, 2015, at 9:34 AM, Brendan Eich wrote: > Allen Wirfs-Brock wrote: >> There is no such thing as a symbol valued property key that is not exposed via reflection. > > Sure -- the idea was to make the symbol spec-internal, even use an abs

Re: Clarification regarding "top level" arrow functions and "this"/"arguments"

Felix Kling wrote: [Section 14.2.17](https://people.mozilla.org/~jorendorff/es6-draft.html#sec-arrow-function-definitions-runtime-semantics-evaluation) says Any reference to `arguments`, `super`, or `this` within an *ArrowFunction* are resolved to their bindings in the lexically enclosing fu

Re: @@toStringTag spoofing for null and undefined

Allen Wirfs-Brock wrote: There is no such thing as a symbol valued property key that is not exposed via reflection. Sure -- the idea was to make the symbol spec-internal, even use an abstract operation rather than a symbol -- anything to provide a spec hook for WHATWG/W3C specs to build on,

Re: @@toStringTag spoofing for null and undefined

Mark S. Miller wrote: Good, I understand now. I agree with all this. In ES6 the common cases have to work right, and no guarantees compromised. Beyond the common cases, extensibility we're confident in is great now. Otherwise, place restriction where needed now (static and dynamic errors, inacc

Re: @@toStringTag spoofing for null and undefined

Mark S. Miller wrote: I understood and agree with everything (or close enough) until your last: On Tue, Jan 20, 2015 at 7:20 PM, Brendan Eich <mailto:bren...@mozilla.org>> wrote: ISTM we need more definite consensus on branding to finish off toStringTag in ES6. What we d

Re: @@toStringTag spoofing for null and undefined

Mark S. Miller wrote: On Tue, Jan 20, 2015 at 4:44 PM, David Ungar > wrote: Oh, the troubles with email. I’ll try again: Self stratifies things into base- and meta- level. The idea is that almost all code is better off sticking to base level because th

Re: @@toStringTag spoofing for null and undefined

Mark S. Miller wrote: Hmm, maybe -- but does Self have a reference-identity equivalence-relation operator that can't be spoofed? Might help to ask David, but to abstract from that particular SPLASH 2011 Q&A, obviously we won't be enabling such fakery in JS. I don't get it. Wha

Re: @@toStringTag spoofing for null and undefined

Mark S. Miller wrote: (2) can't be meta-programmed to spoof identity. But it doesn't leave anything like nominal types as found in many languages lying around as an attractive nuisance (and how, in Java!). What I think I remember hearing from Tom is that Dave's main point, and th

Re: @@toStringTag spoofing for null and undefined

Brendan Eich wrote: 2. Any remaining brand or trademark test can use object identity or equivalent unforgeable capability. (2) can't be meta-programmed to spoof identity. Reference identity, of course -- value types/proxies want value identity defined by concatenating and freezing exi

Re: @@toStringTag spoofing for null and undefined

Mark S. Miller wrote: IIRC David Ungar's question to Tom was "why not enable proxies to mega-program every base-level operation in the language?" I took this to mean nothing like a nominal type check could evade proxying, in David's vision. Is this plausible in your view? No it

Re: @@toStringTag spoofing for null and undefined

Brendan Eich wrote: IIRC David Ungar's question to Tom was "why not enable proxies to mega-program every base-level operation in the language?" LOLtypo: "meta-" not "mega-", of course. /be ___ es-discuss mailin

Re: Setting this to null instead of throwing ReferenceError in a derived class' constructor

Ryosuke Niwa wrote: Having said that, TDZ was introduced to give "let", "const", and alike a sensible behavior as I understand it. Since "this" was never defined by "let" or "const", it seems a little arbitrary and inconsistent to make "this" TDZ only inside a derived class's constructor. It

Re: @@toStringTag spoofing for null and undefined

Mark S. Miller wrote: Yes, we want to complete the MOP so nominal types are equivalent to branded structural types, a la Modula 3, and per David Ungar's position articulated many times over the years (I heard David say it to Tom Van Cutsem in person at SPLASH 2011, re: Proxies n

Re: Array.prototype.contains solutions

Domenic Denicola wrote: https://www.google.com/search?q=site%3Aesdiscuss.org+Array.prototype.contains+solutions leads tohttps://esdiscuss.org/topic/array-prototype-contains-solutions which is probably what you were thinking of. They were not very good ideas. It's a hard problem. Original-J

Re: @@toStringTag spoofing for null and undefined

Domenic Denicola wrote: From: Brendan Eich [mailto:bren...@mozilla.org] > Can we get a leg up, rather than wait for a f2f? This thread seems fine for further discussion and simplifying proposals. Well, to be clear, I'd prefer we not change anything at all. It's too late to

Re: @@toStringTag spoofing for null and undefined

Can we get a leg up, rather than wait for a f2f? This thread seems fine for further discussion and simplifying proposals. /be Domenic Denicola wrote: I think we should remove those anti-spoofing "protections". I anticipate a discussion at TC39 next week. _

Re: es-discuss Digest, Vol 95, Issue 45

Kevin Smith wrote: They're currently spec'ed to throw. I wouldn't change that for ES6. It could change in the future. Granted. However, I don't think we should consider the design complete without an answer to this question, regardless of what gets specced for ES6. The answer may

Re: Destructuring `undefined` and `null`

Allen Wirfs-Brock wrote: see https://bugs.ecmascript.org/show_bug.cgi?id=3574 already fix in my working draft Ok, so the ToObject always runs first. Sounds better on short reflection -- thanks! /be ___ es-discuss mailing list es-discuss@mozilla.or

Re: Destructuring `undefined` and `null`

Why should it throw if there's no [[Get]]? Consider let {x} = o as short for let x = o.x (with o evaluated once and first, in the general case, of course). Then the empty object pattern does nothing and should not throw. This seem best for generated code purposes, it gives a more general bas

Re: Set.prototype.entries: indices as keys?

Brendan Eich wrote: Dmitry Soshnikov wrote: ```js let [x,y] = set; // x='a'; y='b’; ``` Would this work actually? :) Destructuring does get property, which wouldn't call set's `get` method. See http://people.mozilla.org/~jorendorff/es6-draft.h

Re: Set.prototype.entries: indices as keys?

Dmitry Soshnikov wrote: ```js let [x,y] = set; // x='a'; y='b’; ``` Would this work actually? :) Destructuring does get property, which wouldn't call set's `get` method. See http://people.mozilla.org/~jorendorff/es6-draft.html#sec-runtime-semantics-destructuringassignmentevalua

Re: A new ES6 draft is available

Fabrício Matté wrote: I agree with Frankie. Assume a developer who has never seen this `new.target` construct before. In general, ES6 has new syntax, so this is a "learn it and use it" bump, one of many. They will first think that this is an invalid expression, as `new` is an operator. Then

Re: A new ES6 draft is available

Frankie Bagnardi wrote: I'm also expecting a lot of questions about 'what is this new.target thing in this code?', 'is new a variable?', 'where does it come from?', 'isn't new an operator?', etc. if (this instanceof MyDate) ... ... is clearer, but I guess it needs to be disallowed because of

Re: A new ES6 draft is available

Gotta agree new.target is nicer to read and write! /be Allen Wirfs-Brock wrote: err, try { let thisValue = this; //can't reference 'this' prior to 'super()' in a [[Construct]] call of a derived function } catch (e} { calledAsFunction = false //no

Re: Sharing a JavaScript implementation across realms

, Jan 14, 2015 at 1:28 AM, Brendan Eich wrote: Before we go tl;dr on this topic, how about some data to back up the asserted problem size? Filip gently raised the question. How much memory does a realm cost in top open source engines? Fair question, empirical and (I think) not hard to answer

Re: Sharing a JavaScript implementation across realms

Before we go tl;dr on this topic, how about some data to back up the asserted problem size? Filip gently raised the question. How much memory does a realm cost in top open source engines? Fair question, empirical and (I think) not hard to answer. Burdened malloc/GC heap full cost, not net estim

Re: Implicit coercion of Symbols

Indeed, in my first reply on-thread, I wrote "This is exactly the reason." to acknowledge existing consensus. Thanks for linking! /be Domenic Denicola wrote: I re-read through this whole thread and realized nobody brought up the fact that this*specific* change, of making `String(symbol)` wo

Re: (x) => {foo: bar}

Allen Wirfs-Brock wrote: ObjectLiteral is already doing double duty covering ObjectAssignmentPattern. so this would be even more complexity in this area of the grammar. Yeah, the complexity counter-argument is strong. Finally, I'm sort of on the side that this may not be so good for program

Re: (x) => {foo: bar}

Allen Wirfs-Brock wrote: On Jan 6, 2015, at 5:34 PM, Gary Guo wrote: I found that even without shorthand, the object literal can still be ambiguous with block. Yes, but not in the context of a ConciseBody of an ArrowFunction. The grammar for ConciseBody (http://people.mozilla.org/~jorendorf

Re: (x) => {foo: bar}

Dean Landolt wrote: On Tue, Jan 6, 2015 at 3:57 PM, Marius Gundersen > wrote: I don't see how wellLabeledStatement will protect against object literals with shorthand properties, like (x, y, z) => {x, y, z}. It would "protect" against them by disallowing the

Re: {Spam?} Re: (x) => {foo: bar}

Isiah Meadows wrote: Okay: is this a valid statement/expression? I didn't think so, but I may be wrong. ```js ({ foo(); bar(); }) ``` It's a syntax error, in any JS repl or standard. The Node repl only removes parens if it tries adding them first around braced input and that fails. /be

Re: (x) => {foo: bar}

Marius Gundersen wrote: I don't see how wellLabeledStatement will protect against object literals with shorthand properties, like (x, y, z) => {x, y, z}. The solution to the block vs object problem today is to wrap the object in parenthesis, but not the block. The only alternative that is e

Re: (x) => {foo: bar}

Sorry, sent too soon. Dean Landolt wrote: If it's too late to properly vet a change which narrowly excludes from arrow bodies any `LabeledStatement` that isn't a `WellLabeledStatement`, would it be feasible to simply exclude any `LabeledStatement` for now? I doubt there's much code in the wild

Re: (x) => {foo: bar}

Dean Landolt wrote: ISTM there's consensus that this is a footgun -- isn't that a kind of spec bug? No, it's a trade-off, and recent comments in this thread argue against complicating the grammar and real-world parsers, and in favor of teaching people to parenthesize. Nowhere near consensus o

Re: (x) => {foo: bar}

Jasper St. Pierre wrote: Unless x => {foo: bar} and x => {} both parse as object literals, I'm against your proposal. Either un-paren'd braces are consistently a block, or they're consistently an object literal. Python has had major pains with "i before e except after c" rules to m

Re: (x) => {foo: bar}

Mark Volkmann wrote: My apologies. I meant to say that Traceur doesn't support returning a literal object from an arrow function with syntax like this: let f = x => ({foo: bar}); However, I just tested it again and it works fine. I could swear this didn't work a few months ago. Maybe it was f

Re: (x) => {foo: bar}

Caitlin Potter wrote: > You mean replace the footgun with a smaller one, maybe one so small it doesn't matter. Saying that the proposal doesn't get rid of the footgun means it still remains impossible to write x => {p: x} and not get what Frankie and others want: an arrow returning an object. B

Re: (x) => {foo: bar}

Brendan Eich wrote: Kevin Smith wrote: I think hacking around this would not get rid of the footgun, but would just make it more complicated to understand the footgun, personally. My gut reaction is to agree - the current rule, while it takes some trivial learning, is easy to

Re: (x) => {foo: bar}

Kevin Smith wrote: I think hacking around this would not get rid of the footgun, but would just make it more complicated to understand the footgun, personally. My gut reaction is to agree - the current rule, while it takes some trivial learning, is easy to understand and communica

Re: (x) => {foo: bar}

Frankie Bagnardi wrote: That's good news, thanks for the strawman link. Is it correct to assume this with that proposal? var f = (x) => (y) => {x, y}; f(1)(2) // => {x: 1, y: 2}; Good point, the strawman does not take object literal shorthand into account and indeed parses {x, y} in an expr

Re: (x) => {foo: bar}

Caitlin Potter wrote: The strawman changes to the grammar are still ambiguous :( `() => {}` -> noop or Object or SyntaxError? If SyntaxError, ...why? No, the strawman addresses this: "An empty pair of braces |*{}*| other than at start of /Statement/ is an /ObjectLiteral/." The grammar is una

Re: (x) => {foo: bar}

Domenic Denicola wrote: What do you think the chances of this are in ES7+? That is, how backward-compatible is this change? The linked strawman doesn't seem to touch on `() => { foo: bar }` as a back-compat hazard. The strawman discusses compatibility explicitly: http://wiki.ecmascript.org/

Re: (x) => {foo: bar}

See http://wiki.ecmascript.org/doku.php?id=strawman:block_vs_object_literal This could be done, but not for ES6. Sorry I didn't push this harder, earlier. /be Calvin Metcalf wrote: this seems like a footgun and has tripped people up in the wild https://twitter.com/jankrems/status/5446457765

Re: Implicit coercion of Symbols

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 v

Re: {Spam?} Re: Implicit coercion of Symbols

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 pe

Re: Implicit coercion of Symbols

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 method

Re: Implicit coercion of Symbols

Alex Kocharin wrote: 04.01.2015, 05:44, "Rick Waldron" : On Sat Jan 03 2015 at 9:41:57 PM Alex Kocharin > wrote: Also, if you want to prevent mistakes like `object['blah' + symbol]`, linters could be changed to forbid/warn about concatenation inside property

Re: {Spam?} Re: Implicit coercion of Symbols

Alex Kocharin wrote: The code will be incorrect if you pass any regular object in there. Why should symbol be any different? For me, its throwing behavior is just another thing that could crash server-side node.js process for no good reason. No good reason? Wrong. Just because bugs pass with

Re: Octal escape sequences in string and regexp literals

Nevertheless, https://bugs.ecmascript.org/show_bug.cgi?id=3477#c12 makes a good point. IMHO! /be Caitlin Potter wrote: I agree on that point, and therefore I didn't make any refactoring argument. I was referring specifically to C12 (and one other, IIRC) I was referring specifi

Re: Implicit coercion of Symbols

Rick Waldron wrote: That example above is pretty compelling for throw always consistency. With a new Reflect.* API for converting a symbol to its diagnostic/debugging string? If you agree, please file a bugs.ecmascript.org ticket. /be ___ es-discu

Re: Implicit coercion of Symbols

Rick Waldron wrote: Subjectively: I think it's nice in theory, but bad in practice. Compared to what? Converting a symbol to asilent-but-deadly string? I thought you were gonna raise the other way to restore consistency: make String(sym) throw too. Then we'd need a new Reflect op to get a st

Re: Implicit coercion of Symbols

Axel Rauschmayer wrote: On 03 Jan 2015, at 19:52, Brendan Eich <mailto:bren...@mozilla.org>> wrote: None of the objects in the examples bz cited are Arrays -- what did you mean? When I though of `+` being used inside square brackets, I only thought of strings, not of numbers (firs

Re: Implicit coercion of Symbols

None of the objects in the examples bz cited are Arrays -- what did you mean? Symbol must not implicitly convert in *any* object computed-property access to string. /be Axel Rauschmayer wrote: Arrays are a good point, this is where I’d think accidental coercions are most likely. The other u

Re: Implicit coercion of Symbols

Caitlin Potter wrote: One reason it might make sense to throw, is people converting values to string names for use as object properties. Reason you'd want to throw would be to prevent accidentally making the key useless (different from its original Symbol value). This is exactly the reason.

Re: classes and enumerability

Boris Zbarsky wrote: -- so I think the right attack is on the quirky DOM. I think the fundamental assumption that the DOM is "quirky" is broken. Something is quirky if we want mostly-consistent non-enumerability of proto-methods/accessors. Either core built-ins, or DOM. Sorry if "quirky"

Re: classes and enumerability

Sorry, you can't use small-world reasoning about programming in the large, especially with JS on the web. for-in proliferated, before hasOwnProperty appeared in ES3. Even after, the burden was high enough, per that study Allen cited (http://munawarhafiz.com/research/jssurvey/GHB14-JSUsedParts.p

Re: classes and enumerability

Axel Rauschmayer wrote: The alternative is to treat enumerability the way ES6 treats holes: pretend it doesn’t exist: That doesn't work, here or for holes. We've actually split APIs with respect to holes, and this will mean bugs. We did make an intentional future-trumps-past choice against ho

Re: classes and enumerability

Boris Zbarsky wrote: 3) Try to make all "DOM" stuff non-enumerable, dealing with compat issues by adding [LegacyEnumerableProperties] in the few cases where they arise. This risks landing us in the same place as #2 depending on how many interfaces need the annotation, plus compat fallout as w

Re: classes and enumerability

Caitlin Potter wrote: Supposing that methods were non-enumerable by default, would accessors be different, or also non-enumerable by default? Non-enumerable, to match built-ins (RegExp.prototype has some notable accessors). /be ___ es-discuss mail

Re: classes and enumerability

Brendan Eich wrote: There's a confounding variable: the pain of ES6s meta-object APIs, in all respects. I meant "ES5's" here, of course. Agree with Jeremy, laziness is a programmer virtue and a part of human nature. People are not bothering where they don't know be

<    1   2   3   4   5   6   7   8   9   10   >