Inconsistent evaluation order in destructuring assignments
In ES5 all assignments are evaluated following this formula: get a reference via evaluating LHSget a value through evaluating RHSassign the value to the reference However in the current draft, destructuring assignment are evaluated in another order which is (as seen in section 12.13.3) get a value via evaluating RHSparse LHS patternbring parts of RHS into the LHS subpatterns this causes an inconsistency that in expression `[f().x] = [g()]`, g is called BEFORE f. That is weird, and differ from `f().x = g()` where g is called after f. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
use strict 2
I think that we can provide a more strict mode to deal with some long-lasting
defects. In more strict mode,
Implicit type conversion is disabled.Functions declarations are disabled. All
`function(){}` are considered function literal expression.Statement labels are
disabled or strictly restricted.A `break` statement or a fallthrough
declaration is required to be added into the branches inside a switch
statement.`eval` is disabled. ___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Extractors for destructing assignment and pattern matching
I am wondering that whether the current draft have something similar to Scala's
extractors, which could be used in pattern matching.
For example, this pattern:
Email(username, host) = ooxx
is defined as
{let results = Email.unapply(ooxx, 2)if(results !==
undefined) [username, host] = resultselse throw new MisMatchError}
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Should __proto__ be an accessor property of Object.prototype?
The current behaviour of __proto__ looks ugly. The better way might be make
__proto__ an unconfigurable accessor of Object.prototype
Pesudocode:
Object.defineProperty(Object.prototype, '__proto__', { get: function(){ return
Object.getPrototype(this) }, set: function(v){ return
Object.setProrotype(this, v) }, enumerable: false, configurable: false}
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Is __proto__ ready needed?
I think that once an object is created, its prototype should be constant.
And we should add features to implement sub-typing built-in types, like Array,
since this code exists (found in Zepto):
zepto.Z = function(dom, selector) {
dom = dom || []
dom.__proto__ = $.fn
dom.selector = selector || ''
return dom
}
Using proxies may be one way, but it should be more convinent.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
RE: Is __proto__ ready needed?
Maybe some new API, like `createPrototypeModified(obj, newPrototype)`, it
copies all eigen-properties of `obj` to a new object with its prototype is
`newPrototype`.
From: infinte.c...@hotmail.com
To: es-discuss@mozilla.org
Subject: Is __proto__ ready needed?
Date: Mon, 10 Jun 2013 17:06:24 +0800
I think that once an object is created, its prototype should be constant.
And we should add features to implement sub-typing built-in types, like
Array, since this code exists (found in Zepto):
zepto.Z = function(dom, selector) {
dom = dom || []
dom.__proto__ = $.fn
dom.selector = selector || ''
return dom
}
Using proxies may be one way, but it should be more convinent.
___
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
Why semicolon insertion is designed?
I'm wondering that why semicolon insertion is designed and made it anti-intuitive? To provide Java-style syntax compatibility? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Are there any proposals for Tuples?
I mean, a stack-allocated, immutable, simple, value type, for high-performance uses. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: What's the correct behavior for \8 and \9
But, according to spec, \8 and \9 SHOULD cause a syntax error. Because in string literals, EscapeSequence - CharacterEscapeSequence and CharacterEscapeSequence - SingleEscapeCharacterCharacterEscapeSequence - NonEscapeCharacter The NonEscapeCharacter is defined as SourceCharacter minus SingleEscapeCharacter, DecimalDigit, x and u, therefore, 8 and 9 (belongs to DecimalDigit) SHOULD NOT be an element of SingleEscapeCharacter, then not a member of EscapeSequence, therefore, \8 and \9 SHOULD be illegal according to the spec. Date: Sun, 24 Mar 2013 21:38:50 -0700 From: bren...@mozilla.com To: infinte.c...@hotmail.com CC: al...@wirfs-brock.com; es-discuss@mozilla.org Subject: Re: What's the correct behavior for \8 and \9 Right. Here's SpiderMonkey's shell: js \8 8 js \9 9 js \08 \x008 js \09 \x009 js use strict; \8 8 js use strict; \9 9 js use strict; \08 typein:7:0 SyntaxError: octal literals and octal escape sequences are deprecated: typein:7:0 use strict; \08 typein:7:0 ..^ js use strict; \09 typein:8:0 SyntaxError: octal literals and octal escape sequences are deprecated: typein:8:0 use strict; \09 typein:8:0 ..^ /be BelleveInvis wrote: However, \8 and \9 DOES NOT belong to OctalEscapeSequences. There is NO octal number contains 8 or 9. Subject: Re: What's the correct behavior for \8 and \9 From: al...@wirfs-brock.com Date: Sun, 24 Mar 2013 17:22:13 -0700 CC: bren...@mozilla.com; es-discuss@mozilla.org To: infinte.c...@hotmail.com On Mar 24, 2013, at 6:32 AM, BelleveInvis wrote: However, even in the newest draft, \8 still should cause a syntax error. Should we change the production /EscapeCharacter/-/DecimalDigit/ into /EscapeCharacter/-/OctalDigit/ in order to make 8 and 9 belongs to/NonEscapeCharacter/? Probably, but need to look carefully at any possible spec. interactions with OctalEscapeSequences defined in Annex B. (Note that in ES5 we make octal escapes illegal in strict mode code, but they are still allowed in non-strict code) Allen Date: Sat, 23 Mar 2013 13:58:41 -0700 From:bren...@mozilla.com mailto:bren...@mozilla.com To:infinte.c...@hotmail.com mailto:infinte.c...@hotmail.com CC:es-discuss@mozilla.org mailto:es-discuss@mozilla.org Subject: Re: What's the correct behavior for \8 and \9 BelleveInvis wrote: According to spec: Syntax error, because of that 8 or 9 does not belongs to /NonEscapeCharacter/. However, ALL browsers treat them as 8 and 9. Web compatibility seems to require noctal escapes in string literals. No one has really investigated how much web content, but it was true in the past and engines don't like taking risk for little gain. /be ___ es-discuss mailing list es-discuss@mozilla.org mailto: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: What's the correct behavior for \8 and \9
However, even in the newest draft, \8 still should cause a syntax error. Should we change the production EscapeCharacter - DecimalDigit into EscapeCharacter - OctalDigit in order to make 8 and 9 belongs to NonEscapeCharacter? Date: Sat, 23 Mar 2013 13:58:41 -0700 From: bren...@mozilla.com To: infinte.c...@hotmail.com CC: es-discuss@mozilla.org Subject: Re: What's the correct behavior for \8 and \9 BelleveInvis wrote: According to spec: Syntax error, because of that 8 or 9 does not belongs to /NonEscapeCharacter/. However, ALL browsers treat them as 8 and 9. Web compatibility seems to require noctal escapes in string literals. No one has really investigated how much web content, but it was true in the past and engines don't like taking risk for little gain. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: What's the correct behavior for \8 and \9
However, even in the newest draft, \8 still should cause a syntax error. Should we change the production EscapeCharacter - DecimalDigit into EscapeCharacter - OctalDigit in order to make 8 and 9 belongs to NonEscapeCharacter? Date: Sat, 23 Mar 2013 13:58:41 -0700 From: bren...@mozilla.com To: infinte.c...@hotmail.com CC: es-discuss@mozilla.org Subject: Re: What's the correct behavior for \8 and \9 BelleveInvis wrote: According to spec: Syntax error, because of that 8 or 9 does not belongs to /NonEscapeCharacter/. However, ALL browsers treat them as 8 and 9. Web compatibility seems to require noctal escapes in string literals. No one has really investigated how much web content, but it was true in the past and engines don't like taking risk for little gain. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: What's the correct behavior for \8 and \9
However, \8 and \9 DOES NOT belong to OctalEscapeSequences. There is NO octal number contains 8 or 9. Subject: Re: What's the correct behavior for \8 and \9 From: al...@wirfs-brock.com Date: Sun, 24 Mar 2013 17:22:13 -0700 CC: bren...@mozilla.com; es-discuss@mozilla.org To: infinte.c...@hotmail.com On Mar 24, 2013, at 6:32 AM, BelleveInvis wrote:However, even in the newest draft, \8 still should cause a syntax error. Should we change the production EscapeCharacter -DecimalDigit into EscapeCharacter - OctalDigit in order to make 8 and 9 belongs to NonEscapeCharacter? Probably, but need to look carefully at any possible spec. interactions with OctalEscapeSequences defined in Annex B. (Note that in ES5 we make octal escapes illegal in strict mode code, but they are still allowed in non-strict code) Allen Date: Sat, 23 Mar 2013 13:58:41 -0700 From: bren...@mozilla.com To: infinte.c...@hotmail.com CC: es-discuss@mozilla.org Subject: Re: What's the correct behavior for \8 and \9 BelleveInvis wrote: According to spec: Syntax error, because of that 8 or 9 does not belongs to /NonEscapeCharacter/. However, ALL browsers treat them as 8 and 9. Web compatibility seems to require noctal escapes in string literals. No one has really investigated how much web content, but it was true in the past and engines don't like taking risk for little gain. /be ___ 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
What's the correct behavior for \8 and \9
According to spec: Syntax error, because of that 8 or 9 does not belongs to NonEscapeCharacter.However, ALL browsers treat them as 8 and 9. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
FW: Unicode Escape sequences for keywords, what's the correct behaviour?
If a keyword represented as unicode escape sequences, should it interpreted as identifier or keyword? Example code: \u0076\u0061\u0072 a Should it throw a syntax error? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Unicode Escape sequences for keywords, what's the correct behaviour?
Subject: Re: Unicode Escape sequences for keywords, what's the correct behaviour? From: al...@wirfs-brock.com Date: Thu, 21 Mar 2013 08:41:35 -0700 CC: es-discuss@mozilla.org To: infinte.c...@hotmail.com As a keyword. This is clarified in the ES6 draft (http://people.mozilla.org/~jorendorff/es6-draft.html#sec-7.6.1 ) Allen On Mar 21, 2013, at 3:04 AM, BelleveInvis wrote: If a keyword represented as unicode escape sequences, should it interpreted as identifier or keyword? Example code: \u0076\u0061\u0072 a Should it throw a syntax error? ___ es-discuss mailing list es-discuss@mozilla.orgmailto:es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss However I detected some weird implementations. In Chrome 25, `\u0076\u0061\u0072 a` throws a syntax error, means that Chrome treat escape sequences as identifier. Though IE10 runs `\u0076\u0061\u0072 a` well, shows that it treat `\u0076\u0061\u0072` a keyword. Hmmm, perhaps I should establish an issue for Chrome. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Unicode Escape sequences for keywords, what's the correct behaviour?
Hm, Maybe I should establish an issue for Chrome, instead of IE. Thanks. Subject: Re: Unicode Escape sequences for keywords, what's the correct behaviour? From: al...@wirfs-brock.com Date: Thu, 21 Mar 2013 08:41:35 -0700 CC: es-discuss@mozilla.org To: infinte.c...@hotmail.com As a keyword. This is clarified in the ES6 draft (http://people.mozilla.org/~jorendorff/es6-draft.html#sec-7.6.1 ) Allen On Mar 21, 2013, at 3:04 AM, BelleveInvis wrote:If a keyword represented as unicode escape sequences, should it interpreted as identifier or keyword? Example code: \u0076\u0061\u0072 a Should it throw a syntax error? ___ 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: ES Modules: suggestions for improvement
Date: Fri, 27 Jul 2012 09:09:26 -0700 From: bren...@mozilla.org To: infinte.c...@hotmail.com CC: sa...@ccs.neu.edu; es-discuss@mozilla.org Subject: Re: ES Modules: suggestions for improvement BelleveInvis wrote: Date: Tue, 24 Jul 2012 14:11:38 -0700 From: bren...@mozilla.org To: sa...@ccs.neu.edu Subject: Re: ES Modules: suggestions for improvement CC: es-discuss@mozilla.org Sam Tobin-Hochstadt wrote: But I don't think we should ban people from using `import *` because sometimes it's hard to reason about. Just to focus on import *, here's where I am: I'm in favor of deferring (not to say cutting) import *, in order to get ES6 modules spec'ed and avoid protracted maybe-good/maybe-bad arguments. If someone prototyping or REPL'ing feels the pain, they should wail in agony. Enough wailing and we'll figure out something for their use case -- but not on the critical path for ES6. /be ___ es-discuss mailing list es-discuss@mozilla.org http s://mail.mozilla.org/listinfo/es-discuss Agree. Ok. `import *` is just a variant of `with` No, it's not. /be Only explicitly exposed members? that will be a lot better. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: ES Modules: suggestions for improvement
Date: Tue, 24 Jul 2012 14:11:38 -0700 From: bren...@mozilla.org To: sa...@ccs.neu.edu Subject: Re: ES Modules: suggestions for improvement CC: es-discuss@mozilla.org Sam Tobin-Hochstadt wrote: But I don't think we should ban people from using `import *` because sometimes it's hard to reason about. Just to focus on import *, here's where I am: I'm in favor of deferring (not to say cutting) import *, in order to get ES6 modules spec'ed and avoid protracted maybe-good/maybe-bad arguments. If someone prototyping or REPL'ing feels the pain, they should wail in agony. Enough wailing and we'll figure out something for their use case -- but not on the critical path for ES6. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss Agree. `import *` is just a variant of `with` -- everyone knows it is evil. `import x, y, z from xxx` is enough for most cases. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
