>>> * 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
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) -> [ un
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
s
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 ::
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 ES3
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 included
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
this._na
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 sc
On Tue, Dec 11, 2012 at 1:27 PM, Allen Wirfs-Brock wrote:
> >> 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 functional
On Dec 11, 2012, at 10:19 AM, Mark S. Miller wrote:
> On Tue, Dec 11, 2012 at 10:12 AM, Allen Wirfs-Brock
> 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 super r
On Tue, Dec 11, 2012 at 1:12 PM, Allen Wirfs-Brock wrote:
>
> On Dec 11, 2012, at 10:00 AM, Rick Waldron wrote:
>
>
>
>
> On Tue, Dec 11, 2012 at 12:28 PM, Allen Wirfs-Brock > wrote:
>
>> I'm the past we discussed issues surrounding the semantic differences
>> between "put" and "define" and we've
On Tue, Dec 11, 2012 at 10:12 AM, Allen Wirfs-Brock
wrote:
>
> On Dec 11, 2012, at 10:00 AM, Rick Waldron wrote:
>
>
>
>
> On Tue, Dec 11, 2012 at 12:28 PM, Allen Wirfs-Brock
> wrote:
>>
>> I'm the past we discussed issues surrounding the semantic differences
>> between "put" and "define" and we'
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 object
On Dec 11, 2012, at 10:00 AM, Rick Waldron wrote:
>
>
>
> On Tue, Dec 11, 2012 at 12:28 PM, Allen Wirfs-Brock
> 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
> also disc
On Tue, Dec 11, 2012 at 12:28 PM, Allen Wirfs-Brock
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 also discussed Object.define but have not yet made a decision
> to include it
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
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 is
On 10 December 2012 21:59, Claus Reinke 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 stepwise-refinement-starting-from-undefined
>
18 matches
Mail list logo
