Allen and I had a conversation that clarified things.
Essentially, the plan is to only have
[[PreventExtensions]]/[[IsExtensible]] internal MOP methods, and to only
have the corresponding preventExtensions/isExtensible traps for proxies.
Proxies won't have isSealed, isFrozen, seal and frozen trap
On 18 March 2013 18:18, Brendan Eich wrote:
> Andreas Rossberg wrote:
>>
>> On 18 March 2013 17:43, Brendan Eich wrote:
>>>
>>> Andreas Rossberg wrote:
In the process of adopting the new __proto__ semantics, we have
recently changed it to be a magic data property on Object.prototyp
On Mon, Mar 18, 2013 at 1:17 PM, Brendan Eich wrote:
> With a custom loader, sure. Possibly this can be made into a one-liner.
The constructor for new loaders takes a global as an argument. So
yes, this is a one-liner.
Sam
___
es-discuss mailing list
Kevin Smith wrote:
FWIW, in my estimation, tagless template strings which interpolate by
default are one of the top 5 usability improvements in ES6.
Agreed.
Dave's point, that the use-cases for tagless template strings outnumber
innerHTML XSS-concern use-cases by a large factor, is important.
Andreas Rossberg wrote:
On 18 March 2013 17:43, Brendan Eich wrote:
Andreas Rossberg wrote:
In the process of adopting the new __proto__ semantics, we have
recently changed it to be a magic data property on Object.prototype.
In a next step, we will make it a proper JS accessor property.
Are y
Andreas Rossberg wrote:
On 18 March 2013 17:48, Brendan Eich wrote:
Andreas Rossberg wrote:
Maybe I misunderstand what you mean, but unfortunately, the global
object will remain at the top of the scope chain in ES6, even with
modules (though complemented with a lexical environment for new
bind
Wasn't there some talk about an option to remove global from a
module's scope chain? Probably in the module loader? I seem to
remember that being discussed. I don't, however, remember ever seeing
a decision for or against such a solution.
On Mon, Mar 18, 2013 at 6:04 PM, Mark S. Miller wrote:
> S
Sadness. I had misremembered how all that finally resolved. In that moment,
I thought we had decided to fix that for modules. But now that you mention
it, I remember the discussion. These are difficult issues, and I was not
trying to suggest we reopen them.
In any case, regarding the new #1 and #3
Le 18/03/2013 17:48, Brendan Eich a écrit :
Andreas Rossberg wrote:
On 18 March 2013 17:32, Mark S. Miller wrote:
And why does ES5/strict impose these restrictions, when they are not
necessary for the formal criterion?
Because ES5 strict mode, being an opt-in, gave us a rare opportunity to
cl
FWIW, in my estimation, tagless template strings which interpolate by
default are one of the top 5 usability improvements in ES6.
{ Kevin }
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On 18 March 2013 17:48, Brendan Eich wrote:
> Andreas Rossberg wrote:
>>
>> On 18 March 2013 17:32, Mark S. Miller wrote:
>>>
>>> And why does ES5/strict impose these restrictions, when they are not
>>> necessary for the formal criterion?
>>>
>>> Because ES5 strict mode, being an opt-in, gave us
On 18 March 2013 17:43, Brendan Eich wrote:
> Andreas Rossberg wrote:
>> In the process of adopting the new __proto__ semantics, we have
>> recently changed it to be a magic data property on Object.prototype.
>> In a next step, we will make it a proper JS accessor property.
>
> Are you poisoning r
Andreas Rossberg wrote:
On 18 March 2013 17:32, Mark S. Miller wrote:
And why does ES5/strict impose these restrictions, when they are not
necessary for the formal criterion?
Because ES5 strict mode, being an opt-in, gave us a rare opportunity to
clean things up in preparation for yet better s
On 18 March 2013 17:32, Mark S. Miller wrote:
> And why does ES5/strict impose these restrictions, when they are not
> necessary for the formal criterion?
>
> Because ES5 strict mode, being an opt-in, gave us a rare opportunity to
> clean things up in preparation for yet better scoping in ES6. I'm
Andreas Rossberg wrote:
On 16 March 2013 00:00, Kevin Reid wrote:
I'm doing a little maintenance on SES. Chrome has recently added a new
odd behavior:
var o = Object.create(null);
Object.getOwnPropertyNames(o)
[]
Object.getOwnPropertyDescriptor(o, '__proto__');
Object {value: null, writabl
Interesting thread. After all this work trying to figure out what I meant,
I'm sorry to disappoint. Technically, Domenic is right: once we are rid of
"with" and non-strict "eval", #1 and #3 do not technically violate the
degree of static scoping provided by ES5.
So why are they on this list?
Beca
I certainly agree, but it has been decided otherwhise by the TC39 members and I
doubt they’re willing to revert their decision.
De : Andrea Giammarchi
Envoyé : 18 mars 2013 17:08
À : Nathan Wall
Cc : es-discuss@mozilla.org
Objet : Re: Mutable Proto
I would like to see Object.set
I would like to see Object.setPrototypeOf(object, proto) too and a
disappeared __proto__ 'till now breaking too much.
It would be much easier to implement all shenanigans via
Object.defineProperty(Object.prototype, '__proto__', {whatever}); rather
than fix current non-standard __proto__ ...
+1
A previous thread [1] brought to my attention the fact that objects which don't
inherit from Object.prototype won't have mutable __proto__. This was something
I had missed and breaks some scripts I'm currently using because I have objects
which I don't want to inherit from Object.prototype but
# March 13 2013 Meeting Notes
John Neumann (JN), Norbert Lindenberg (NL), Allen Wirfs-Brock (AWB), Rick
Waldron (RW), Waldemar Horwat (WH), Eric Ferraiuolo (EF), Erik Arvidsson
(EA), Luke Hoban (LH), Matt Sweeney (MS), Doug Crockford (DC), Yehuda Katz
(YK), Brendan Eich (BE), Sam Tobin-Hochstadt (
Ok, somehow I had completely missed "9.3.10 TestIntegrityLevel (O, level)"
which does exactly the derived computation for sealed and frozen objects.
I think André is right though about the bug in 8.3.3 step 2.a.
Cheers,
Tom
2013/3/17 Allen Wirfs-Brock
> Tom recently suggested that that we real
On 16 March 2013 07:34, Allen Wirfs-Brock wrote:
>
> On Mar 15, 2013, at 5:55 PM, Waldemar Horwat wrote:
>
>> On 03/14/2013 04:14 PM, Brendan Eich wrote:
>>> Andreas Rossberg wrote:
On 14 March 2013 23:38, Brendan Eich wrote:
> Andreas Rossberg wrote:
>> That leaves my original propo
From: Sam Tobin-Hochstadt
> On Mon, Mar 18, 2013 at 8:40 AM, Andreas Rossberg wrote:
>>
>> Nothing, but Sam probably meant to write:
>>
>> if (something_random()) xxx = 7;
>> xxx; // ReferenceError or not?
>
> Right, I was confusing the problem this code describes, which is what I think
> Mark
On Mon, Mar 18, 2013 at 8:40 AM, Andreas Rossberg wrote:
>
> Nothing, but Sam probably meant to write:
>
> if (something_random()) xxx = 7;
> xxx; // ReferenceError or not?
Right, I was confusing the problem this code describes, which is what
I think Mark meant, with the problem of the global obj
On 18 March 2013 13:28, Domenic Denicola wrote:
> On Mar 18, 2013, at 7:54, "Sam Tobin-Hochstadt" wrote:
>
>> On Sun, Mar 17, 2013 at 11:44 PM, Domenic Denicola
>> wrote:
>>>
>>> 1. implicit global variable creation
>>> 2. `with`
>>> 3. `delete`ing free variables
>>> 4. `eval` introducing local
On Mar 18, 2013, at 7:54, "Sam Tobin-Hochstadt" wrote:
> On Sun, Mar 17, 2013 at 11:44 PM, Domenic Denicola
> wrote:
>>
>> 1. implicit global variable creation
>> 2. `with`
>> 3. `delete`ing free variables
>> 4. `eval` introducing local bindings
>>
>> 2 and 4 make perfect sense, but I don't un
On Sun, Mar 17, 2013 at 11:44 PM, Domenic Denicola
wrote:
>
> 1. implicit global variable creation
> 2. `with`
> 3. `delete`ing free variables
> 4. `eval` introducing local bindings
>
> 2 and 4 make perfect sense, but I don't understand how 1 and 3 interfere with
> static scoping. In particular,
Herby Vojčík wrote:
Axel Rauschmayer wrote:
A few more thoughts:
- This marks the end of prototypal inheritance in JavaScript (not
complaining, just stating a fact). Putting @@create in constructors C
makes a lot of sense, but it could, in principle, also be put into
instance prototypes C.p
Axel Rauschmayer wrote:
A few more thoughts:
- This marks the end of prototypal inheritance in JavaScript (not
complaining, just stating a fact). Putting @@create in constructors C
makes a lot of sense, but it could, in principle, also be put into
instance prototypes C.prototype. Then Object.c
A few more thoughts:
- This marks the end of prototypal inheritance in JavaScript (not complaining,
just stating a fact). Putting @@create in constructors C makes a lot of sense,
but it could, in principle, also be put into instance prototypes C.prototype.
Then Object.create(proto) could use @@
I think the idea of detecting if you have initialized or noninitialized
instance at runtime is very unhappy idea.
You know when it is called as an initializer (2, 4 below) and when not
(1 below). 3 below is legacy way of doing super - it can be simply replaced.
And there is also no breaking c
On 16 March 2013 00:00, Kevin Reid wrote:
> I'm doing a little maintenance on SES. Chrome has recently added a new
> odd behavior:
>
>> var o = Object.create(null);
>> Object.getOwnPropertyNames(o)
> []
>> Object.getOwnPropertyDescriptor(o, '__proto__');
> Object {value: null, writable: true, enum
32 matches
Mail list logo
