On 10 December 2012 21:59, Claus Reinke claus.rei...@talk21.com wrote:
Second, it doesn't eliminate the need for temporal dead zones at all.
You could well be right, and I might have been misinterpreting what
temporal dead zone (tdz) means.
For a letrec, I expect
I'm the past we discussed issues surrounding the semantic differences between
put and define and we've agreed to include Object.assign in ES6. We have
also discussed Object.define but have not yet made a decision to include it.
Nicholas Zaka recently posted a short article that addresses
Wholeheartedly agree with this. For library authoring it's a necessity, so
a define like function is always the first thing in any .js file I make.
The need for library authors is obvious but if I recall the conclusion was
that those authors would be able to handle it themselves and to push off on
On Tue, Dec 11, 2012 at 12:28 PM, Allen Wirfs-Brock
al...@wirfs-brock.comwrote:
I'm the past we discussed issues surrounding the semantic differences
between put and define and we've agreed to include Object.assign in
ES6. We have also discussed Object.define but have not yet made a decision
On Dec 11, 2012, at 10:00 AM, Rick Waldron wrote:
On Tue, Dec 11, 2012 at 12:28 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
I'm the past we discussed issues surrounding the semantic differences between
put and define and we've agreed to include Object.assign in ES6. We have
Agreed, getOwnPropertyNames is way more appropriate if the topic is: use
all ES5 features for mixins too.
Also, the Nicolas example is potentially disaster prone, not in that
specific form, but in the way a getter with private scope access could be.
Imagine many objects using that specific
On Tue, Dec 11, 2012 at 10:12 AM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
On Dec 11, 2012, at 10:00 AM, Rick Waldron wrote:
On Tue, Dec 11, 2012 at 12:28 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
I'm the past we discussed issues surrounding the semantic differences
On Tue, Dec 11, 2012 at 1:12 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
On Dec 11, 2012, at 10:00 AM, Rick Waldron wrote:
On Tue, Dec 11, 2012 at 12:28 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
I'm the past we discussed issues surrounding the semantic differences
On Dec 11, 2012, at 10:19 AM, Mark S. Miller wrote:
On Tue, Dec 11, 2012 at 10:12 AM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
Except,
1) It needs to iterate own keys, not just string valued property names so it
will pick up properties whose keys are symbols
2) It needs to rebind
On Tue, Dec 11, 2012 at 1:27 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
2) It needs to rebind super references
3) I don't see any reason that it should be restricted to enumerable
properties. If the intend is to deprecate enumerable along with for-in
then
we should be adding new
On Dec 11, 2012, at 10:19 AM, Andrea Giammarchi wrote:
Agreed, getOwnPropertyNames is way more appropriate if the topic is: use all
ES5 features for mixins too.
Also, the Nicolas example is potentially disaster prone, not in that specific
form, but in the way a getter with private scope
what I think is a very valid use case for mixins based on ES5 features
var MixIt = Object.defineProperties({}, {
name: {
enumerable: true,
get: function () {
// notify or do stuff
return this._name;
},
set: function (_name) {
// notify or do stuff
http://github.com/benvie/continuum - project
http://benvie.github.com/continuum - debugger
npm module 'continuum'
Continuum is a virtual machine for executing ES6 code (the spec is rapidly
iterating so many things need updating). It's written in ES3 and targets a
baseline of IE8 (debugger
Le 11/12/2012 21:46, Brandon Benvie a écrit :
http://github.com/benvie/continuum - project
http://benvie.github.com/continuum - debugger
npm module 'continuum'
Continuum is a virtual machine for executing ES6 code (the spec is
rapidly iterating so many things need updating). It's written in
I am currently working on building an executable version of the
semantics of regular expression pattern matching, and I think I've found
in a bug in how they are specified in both the released version of
ECMA-262 and the latest working draft.
In §15.10.2.5, it says that:
The production Term
Agree with all you said. And practically speaking, if I intend to support
these things in a piece of software I've written then somewhere, somehow,
there needs to be a way to tell that they work. Right now there's a lot of
things that ostensibly are supported by Continuum but for which the way to
I would still love to have something like that in ES6 (loosely similar to
String.prototype.repeat). Once you have that, you can e.g. use
Array.prototype.map to do more things.
Two possibilities:
- Array.repeat(undefined, 3) - [ undefined, undefined, undefined ]
- [ undefined ].repeat(3) - [
* It deoptimizes, e.g. a strict-mode function must be optimized to copy
actual parameter values into arguments if it could use the arguments object.
This one I just don't buy at all. In a strict function f, f.arguments
is poisoned. f's arguments would only need to be reified if f
statically
18 matches
Mail list logo
