Andrea Giammarchi wrote:
can I also suggest to analyze, if there's still any doubt left on a
method VS a property yet, this piece of code if not highlighted before?
I do not understand what you mean here.
Behavior in Safari and FirefoxNightly (V8 still by its own here)
```
var obj =
2013/5/20 Andrea Giammarchi andrea.giammar...@gmail.com
I believe having a counterpart in the Object, following a natural
expectation where for a get you've got a set, is just fine but surely
Reflect should have its own reflection power a part.
Yeah, given the existence of
On Tue, May 21, 2013 at 12:56 AM, Brendan Eich bren...@mozilla.com wrote:
Andrea Giammarchi wrote:
can I also suggest to analyze, if there's still any doubt left on a
method VS a property yet, this piece of code if not highlighted before?
I do not understand what you mean here.
I mean
for always work I meant as long as the object is not sealed/frozen as
discussed a while ago
On Tue, May 21, 2013 at 9:43 AM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
On Tue, May 21, 2013 at 12:56 AM, Brendan Eich bren...@mozilla.comwrote:
Andrea Giammarchi wrote:
can I also
On 5/21/2013 9:43 AM, Andrea Giammarchi wrote:
On Tue, May 21, 2013 at 12:56 AM, Brendan Eich bren...@mozilla.com
mailto:bren...@mozilla.com wrote:
Andrea Giammarchi wrote:
can I also suggest to analyze, if there's still any doubt left
on a method VS a property yet, this
consider this then, same thing JSON is doing now in FF and Safari
```
var obj = Object.defineProperty({}, '__proto__', {
enumerable: true,
writable: true,
configurable: true,
value: []
});
console.log(obj instanceof Array); // false
obj.__proto__ = Array.prototype;
console.log(obj
2013/5/9 Brendan Eich bren...@mozilla.com
Andreas Rossberg wrote:
(And let's bury setPrototypeOf quickly.)
Bury how? IIUC this goes in main spec alongside ES5's
Object.getPrototypeOf, requires a proxy trap, etc.
Here's one potential alternative: add Reflect.setPrototypeOf but not
does `Proxy` trap `Object.getPrototypeOf` somehow ?
If yes, why do you think having two namespaces for the prototype operation
is better?
If not, why do you think that is not needed in case of getting the
prototype?
In any case, how `Object.setPrototypeOf` differs anyhow compared to how the
2013/5/20 Andrea Giammarchi andrea.giammar...@gmail.com
does `Proxy` trap `Object.getPrototypeOf` somehow ?
If yes, why do you think having two namespaces for the prototype operation
is better?
If not, why do you think that is not needed in case of getting the
prototype?
Yes, there's a
I believe having a counterpart in the Object, following a natural
expectation where for a get you've got a set, is just fine but surely
Reflect should have its own reflection power a part.
I see Reflect more like an introspection tool able to understand things and
not necessarily mutate them (
On 5/20/2013 10:55 AM, Andrea Giammarchi wrote:
I believe having a counterpart in the Object, following a natural
expectation where for a get you've got a set, is just fine but surely
Reflect should have its own reflection power a part.
I see Reflect more like an introspection tool able to
that's fine with what I am thinking/saying ... it's used as reflection, to
intercept, or to trap, and not used to do the action of setting the
prototype so `Object` is, and you confirmed this, a better place for
`setPrototypeOf`
On Mon, May 20, 2013 at 11:29 AM, Brandon Benvie
can I ask when is next TC39 meeting?
can I also suggest to analyze, if there's still any doubt left on a method
VS a property yet, this piece of code if not highlighted before?
Behavior in Safari and FirefoxNightly (V8 still by its own here)
```
var obj = JSON.parse('{__proto__:[]}');
On 5/20/2013 5:58 PM, Andrea Giammarchi wrote:
can I ask when is next TC39 meeting?
Starts tomorrow. http://wiki.ecmascript.org/doku.php?id=meetings:meetings
___
es-discuss mailing list
es-discuss@mozilla.org
Le 09/05/2013 18:14, Brendan Eich a écrit :
Andreas Rossberg wrote:
But not __proto__ -- dream on if you think that is going away any
time soon!
I was thinking about V8 embedders other than browsers who could toggle
that flag.
Node won't, if I recall correctly. Any other embeddings of
On 8 May 2013 22:58, Brendan Eich bren...@mozilla.com wrote:
Andreas Rossberg wrote:
On 8 May 2013 18:06, David Bruantbruan...@gmail.com wrote:
Le 08/05/2013 08:01, Andreas Rossberg a écrit :
On 8 May 2013 07:10, Mark Millererig...@gmail.com wrote:
What would be gained by
moving the
I would rather bury __proto__ sooner through a
--no-black-magic-in-object-prototype V8 flag but again, I proposed a flag
and V8 said they don't want to go for this direction ... **actually it was
you saying that**
https://code.google.com/p/v8/issues/detail?id=2645#c3
We have no interest in
Jeff Walden wrote:
On 05/08/2013 04:10 PM, Brendan Eich wrote:
Why would Object.setPrototypeOf have any better perf?
It wouldn't.
Then I don't know why you wrote The reason would be to cordon off
functionality whose mis-performance developers will not intuitively
understand, so that
Andreas Rossberg wrote:
But not __proto__ -- dream on if you think that is going away any time soon!
I was thinking about V8 embedders other than browsers who could toggle
that flag.
Node won't, if I recall correctly. Any other embeddings of note?
And I absolutely do think that should
On 05/09/2013 10:12 AM, Brendan Eich wrote:
Adding an equivalent to the main spec does not cordon off the mis-performing
(non-performant?) functionality.
I may have misread, but I had thought there was argument to put
Object.setPrototypeOf in Annex B as well. If it's added, that seems like
Jeff Walden wrote:
On 05/09/2013 10:12 AM, Brendan Eich wrote:
Adding an equivalent to the main spec does not cordon off the mis-performing
(non-performant?) functionality.
I may have misread, but I had thought there was argument to put
Object.setPrototypeOf in Annex B as well.
No, main
On 8 May 2013 07:10, Mark Miller erig...@gmail.com wrote:
What would be gained by
moving the property alone to Annex B? If nothing, then I think this
consistency should win.
JavaScript implementations in new or existing eco systems that are not
poisoned by web legacy wouldn't be obliged to
On May 8, 2013, at 12:01 AM, Andreas Rossberg wrote:
On 8 May 2013 07:10, Mark Miller erig...@gmail.com wrote:
What would be gained by
moving the property alone to Annex B? If nothing, then I think this
consistency should win.
JavaScript implementations in new or existing eco systems that
What about your triangle argument?
Cheers
--MarkM
On May 8, 2013, at 7:53 AM, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On May 8, 2013, at 12:01 AM, Andreas Rossberg wrote:
On 8 May 2013 07:10, Mark Miller erig...@gmail.com wrote:
What would be gained by
moving the property
On May 8, 2013, at 8:31 AM, Mark Miller wrote:
What about your triangle argument?
There is another way:
let obj = Object.setPrototypeOf({x:0, y:0}, pointProto};
Let's keep {__proto__: foo} in the slightly disrespectable Annex B box. That
keeps it together with O.p.__proto and leaves room
On 8 May 2013 17:41, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On May 8, 2013, at 8:31 AM, Mark Miller wrote:
What about your triangle argument?
There is another way:
let obj = Object.setPrototypeOf({x:0, y:0}, pointProto};
Let's keep {__proto__: foo} in the slightly disrespectable
Le 08/05/2013 16:46, Andreas Rossberg a écrit :
On 8 May 2013 17:41, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On May 8, 2013, at 8:31 AM, Mark Miller wrote:
What about your triangle argument?
There is another way:
let obj = Object.setPrototypeOf({x:0, y:0}, pointProto};
Let's keep
Le 08/05/2013 08:01, Andreas Rossberg a écrit :
On 8 May 2013 07:10, Mark Miller erig...@gmail.com wrote:
What would be gained by
moving the property alone to Annex B? If nothing, then I think this
consistency should win.
JavaScript implementations in new or existing eco systems that are not
On 5/8/2013 9:00 AM, David Bruant wrote:
Le 08/05/2013 16:46, Andreas Rossberg a écrit :
Isn't Object.create the proper alternative to both {__proto__: } and
triangle for objects? What has setPrototypeOf got to do with it? (And
why is that on the table all of a sudden?)
Object.create only
On 8 May 2013 18:06, David Bruant bruan...@gmail.com wrote:
Le 08/05/2013 08:01, Andreas Rossberg a écrit :
On 8 May 2013 07:10, Mark Miller erig...@gmail.com wrote:
What would be gained by
moving the property alone to Annex B? If nothing, then I think this
consistency should win.
I proposed a flag for a reusable setter they told me they have no interest
to fragment the language behind these kind of flags ...
To all: a new syntax is also more suitable for shims/polyfills, something
broken/partial implementation of __proto__.set descriptor cannot replace
so, as direction,
On May 8, 2013, at 8:46 AM, Andreas Rossberg wrote:
On 8 May 2013 17:41, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On May 8, 2013, at 8:31 AM, Mark Miller wrote:
What about your triangle argument?
There is another way:
let obj = Object.setPrototypeOf({x:0, y:0}, pointProto};
Andreas Rossberg wrote:
On 8 May 2013 18:06, David Bruantbruan...@gmail.com wrote:
Le 08/05/2013 08:01, Andreas Rossberg a écrit :
On 8 May 2013 07:10, Mark Millererig...@gmail.com wrote:
What would be gained by
moving the property alone to Annex B? If nothing, then I think this
Having Object.setPrototypeOf to match Object.getPrototypeOf is nice,
better for proxies (with necessary changes to them), and polyfillable.
Take my last note as an attitude adjustment, though. So long as
__proto__ endures, its brevity and legacy uses will tend to propagate
its use into the
Call me crazy but I can picture a world where you have to explicitly shim
in __proto__ (using Object.setPrototypeOf) if you really need it. Not
anytime soon, sure, but maybe one day. Maybe...
On Wed, May 8, 2013 at 5:05 PM, Brendan Eich bren...@mozilla.com wrote:
Having Object.setPrototypeOf
On 05/08/2013 01:58 PM, Brendan Eich wrote:
1. Dumping stuff into Annex B to show disdain. This is pride, bad for the
soul.
Pride doesn't seem like a reason one way or the other, to me. The reason
would be to cordon off functionality whose mis-performance developers will not
intuitively
Dean Landolt wrote:
Call me crazy but I can picture a world where you have to explicitly
shim in __proto__ (using Object.setPrototypeOf) if you really need it.
Not anytime soon, sure, but maybe one day. Maybe...
Who can say? It's fruitless to speculate idly. Want to bet?
But aside from
Jeff Walden wrote:
On 05/08/2013 01:58 PM, Brendan Eich wrote:
1. Dumping stuff into Annex B to show disdain. This is pride, bad for the soul.
Pride doesn't seem like a reason one way or the other, to me.
Good.
The reason would be to cordon off functionality whose mis-performance
Why
On 05/08/2013 04:10 PM, Brendan Eich wrote:
Why would Object.setPrototypeOf have any better perf?
It wouldn't.
developers will not intuitively understand, so that they're less likely to
use it. Some will, even still, perhaps just out of obstinacy (pride,
I think you missed that that
it took 8 years to teach JS developers **not** to pollute Object.prototype,
I understand your concern and I understand with the possibility to drop
enumerability that could (and will) be proposed by someone.
At the same time it will be a stubborn move aim to fix some deprecated,
old, not
Do you think we can come to some sort of agreement, as discussed below,
that [[ProtoSetter]] doesn't need to be realm restricted. Such an
agreement would let us write the simplest possible specification of
__proto__.
Very timely question. I've discussed this within the other Cajadores
On Tue, May 7, 2013 at 11:09 AM, Nathan Wall nathan.w...@live.com wrote:
Do you think we can come to some sort of agreement, as discussed below,
that [[ProtoSetter]] doesn't need to be realm restricted. Such an
agreement would let us write the simplest possible specification of
__proto__.
fine for non-extensible objects, you might desire to keep a dictionary a
dictionary though, allowing properties extensions avoiding hot-swap
inheritance
2 options in my mind:
1. Object.freezeInheritance(generic), setting a [[MutablePrototype]]
internal property to false (true by default)
2.
So here is the plan that I'll review at the next TC39 meeting:
1) Add Object.setPrototypeOf(obj, proto)
A obj must be extensible in order to change its [[Prototype]]. There are no
realm restrictions. It's just like all the other Object.* methods in operating
on any object, independent of realm
On Tue, May 7, 2013 at 1:52 PM, Allen Wirfs-Brock
allen.wirfsbr...@gmail.com wrote:
So here is the plan that I'll review at the next TC39 meeting:
1) Add Object.setPrototypeOf(obj, proto)
A obj must be extensible in order to change its [[Prototype]]. There are
no realm restrictions. It's
On Tue, May 7, 2013 at 1:59 PM, Mark S. Miller erig...@google.com wrote:
On Tue, May 7, 2013 at 1:52 PM, Allen Wirfs-Brock
allen.wirfsbr...@gmail.com wrote:
So here is the plan that I'll review at the next TC39 meeting:
1) Add Object.setPrototypeOf(obj, proto)
A obj must be extensible in
Looks like a very clean solution. The only thing I’m not entirely convinced
about is Object.setPrototypeOf()...
... given how one is normally discouraged from using such functionality
(=__proto__ as a setter) and
... given that the most frequent use case goes away in ES6 (thanks to it
allowing
Mark S. Miller wrote:
2) Object.prototype.__proto__ is moved back to Annex B.
Since __proto__, unlike __defineGetter__, provides functionality
that is otherwise unavailable, all JS platforms will treat it as
mandatory whether we put it into Appendix B or the main text. At
The special syntax can't go into Annex B; it must remain in the main text.
Allen's message agrees with this. I agree that consistency suggests that
the property go in the main text, but doesn't demand it. What would be
gained by moving the property alone to Annex B? If nothing, then I think
this
Le 23/04/2013 17:52, Allen Wirfs-Brock a écrit :
On Apr 23, 2013, at 5:10 PM, Mark S. Miller wrote:
[*] I say probably to hedge my bets. The hard constraint we
absolutely require is already guaranteed by ES5: That the
[[Prototype]] of a non-extensible object cannot be mutated. Given
that, it
To clarify, since I was perhaps somewhat terse here. :-)
print(eval('[{__proto__: 17}]')[0].hasOwnProperty(__proto__));
print(eval('[{__proto__:0x17}]')[0].hasOwnProperty(__proto__));
SunSpider uses eval() on JSONish input, so engines have to make that fast.
Most/all engines for
On 22 April 2013 22:15, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
We don't currently have the concept of an object belonging to a realm.
Functions have a realm association, but not non-function object.
I thought the current plan of record is to require this check for
reflected uses of
On 23 April 2013 05:11, Mark S. Miller erig...@google.com wrote:
The first two goals generally align well anyway. I think this is best served
by something that seems at least close to what was agreed on:
* The syntax that we've already agreed to on this thread: {__proto__: }
is special
On Apr 23, 2013, at 3:31 AM, Mark S. Miller wrote:
On Mon, Apr 22, 2013 at 1:15 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
We don't currently have the concept of an object belonging to a realm.
Functions have a realm association, but not non-function object.
The current idea on
Aren't sandboxed natives a JS technique that actually relies on cross-realm
prototype chains?
http://msdn.microsoft.com/en-us/magazine/gg278167.aspx
My understanding is that they create a separate origin in order to get
their own copies of the natives so that they can fiddle with those natives'
On 23 April 2013 14:54, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
Even if we had per object realm associations, it isn't clear to me what
exactly we are trying to block WRT cross-realm [[Prototype]] chains. Is the
assertion that all objects in a [[Prototype]] chain must come from the same
Agreed. Just to clarify though, I'm going to make a pedantic change to your
wording ;).
On Tue, Apr 23, 2013 at 6:00 AM, Andreas Rossberg rossb...@google.comwrote:
[...]
Preventing cross-realm prototype chains was not the intention. The
intention was to prevent using a protosetter from
Mark, below what you refer to as [[SetProtoype]] is essentially the
[[SetInhertiance]] MOP operations in the current spec. draft there is also a
[[GetInheritance]]. It is called Get/SetInheritance because it doesn't
necessarily manipulate the [[Prototype]] of the object it is invoked upon (eg,
What is Object.free?
On Tue, Apr 23, 2013 at 6:30 AM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
Mark, below what you refer to as [[SetProtoype]] is essentially the
[[SetInhertiance]] MOP operations in the current spec. draft there is also
a [[GetInheritance]]. It is called
Andreas Rossberg wrote:
On 22 April 2013 22:15, Allen Wirfs-Brockal...@wirfs-brock.com wrote:
We don't currently have the concept of an object belonging to a realm.
Functions have a realm association, but not non-function object.
I thought the current plan of record is to require this
Le 23/04/2013 15:30, Allen Wirfs-Brock a écrit :
* { [ __proto__ ]: } is not special in any way, and creates a normal property
named __proto__.
I don't believe this is legal. Didn't we agree w to support [ ] property keys
that evaluate to symbols.
I don't know what the agreement is, but
Taking bite-sized pieces:
Allen Wirfs-Brock wrote:
* { [ __proto__ ]: } is not special in any way, and creates a normal property named __proto__.
I don't believe this is legal. Didn't we agree w to support [ ] property keys
that evaluate to symbols.
No, [n] is good for any
David Bruant wrote:
Le 23/04/2013 15:30, Allen Wirfs-Brock a écrit :
* { [ __proto__ ]: } is not special in any way, and creates a
normal property named __proto__.
I don't believe this is legal. Didn't we agree w to support [ ]
property keys that evaluate to symbols.
I don't know what the
On Apr 23, 2013, at 3:35 PM, Mark Miller wrote:
What is Object.free?
ugh, jet lag...
Object.freeze
On Tue, Apr 23, 2013 at 6:30 AM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
Mark, below what you refer to as [[SetProtoype]] is essentially the
[[SetInhertiance]] MOP operations
On Apr 23, 2013, at 3:50 PM, Brendan Eich wrote:
Taking bite-sized pieces:
Allen Wirfs-Brock wrote:
* { [ __proto__ ]: } is not special in any way, and creates a
normal property named __proto__.
I don't believe this is legal. Didn't we agree w to support [ ] property
keys
Le 23/04/2013 15:53, Brendan Eich a écrit :
David Bruant wrote:
Le 23/04/2013 15:30, Allen Wirfs-Brock a écrit :
* { [ __proto__ ]: } is not special in any way, and creates
a normal property named __proto__.
I don't believe this is legal. Didn't we agree w to support [ ]
property keys
On Tue, Apr 23, 2013 at 6:30 AM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
Mark, below what you refer to as [[SetProtoype]] is essentially the
[[SetInhertiance]] MOP operations in the current spec. draft there is also
a [[GetInheritance]]. It is called Get/SetInheritance because it
On Apr 23, 2013, at 5:10 PM, Mark S. Miller wrote:
On Tue, Apr 23, 2013 at 6:30 AM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
Mark, below what you refer to as [[SetProtoype]] is essentially the
[[SetInhertiance]] MOP operations in the current spec. draft there is also a
discussion oriented to SES again, I hope this won't be spec'd blindly after
some SES requirement that might be very different from, let's say, node.js
requirements, where the concept of security is not about evaluating runtime
unknonw code ... right? :-)
I keep being amazed by how many problems
be careful what you wish ... if it's about making things that hard on
server side JS too.
V8 apparently won't accept even a flag for this, regardless zero side
effects on web whatever decision is made.
https://code.google.com/p/v8/issues/detail?id=2645
This is bad, IMHO!
On Tue, Apr 23, 2013
You are filing the wrong bug, asking for the wrong thing.
What V8 implemented was based on a misunderstanding of the January
tentative consensus. The setter should not always throw.
We're working through the details to re-establish consensus here, in
advance of the mid-May meeting. In the
On 04/21/2013 03:27 PM, Mark S. Miller wrote:
Warning: The following is a sickening idea. I would really hate to see us do
it. But I feel obliged to post it as it may in fact be the right thing to do.
This suggests that, in JS as well, the __proto__ in {, __proto__:
, } not be
then is more Ha, ha, ha. Lulz, I told you, lulz! this one?
'__proto__' in {__proto__:null,__proto__:null}
On Tue, Apr 23, 2013 at 5:34 PM, Jeff Walden jwalden...@mit.edu wrote:
On 04/21/2013 03:27 PM, Mark S. Miller wrote:
Warning: The following is a sickening idea. I would really hate to
Mark Miller wrote:
On Sun, Apr 21, 2013 at 9:42 PM, Brendan Eich bren...@mozilla.com
mailto:bren...@mozilla.com wrote:
Ok, so (after pushing back based on recorded consensus, which I
think is fair), I'm ok with
* Object.prototype.__proto__ is configurable.
* o = {__proto__:
I have difficulties catching up with everything that has been said in
this thread, my apologies if I repeat parts of the discussion. Here is
what I thought we agreed upon earlier:
1. __proto__ is an accessor property on Object.prototype
2. reflecting it via Object.getOwnPropertyDescriptor gives
Andreas Rossberg wrote:
I have difficulties catching up with everything that has been said in
this thread, my apologies if I repeat parts of the discussion. Here is
what I thought we agreed upon earlier:
1. __proto__ is an accessor property on Object.prototype
2. reflecting it via
On 22 April 2013 15:49, Brendan Eich bren...@mozilla.com wrote:
However, in that case, I actually think that there is no need to have
any special poisoning semantics when reflecting __proto__ -- mainly
because the cross-realm check is already necessary in the unreflected
case: you can
We don't currently have the concept of an object belonging to a realm.
Functions have a realm association, but not non-function object.
Object.create(parent);//we have no way to determine if parent belongs to
the same realm as Object.create.
we also currently have no way to determine
then what's the point to poison
Object.getOwnPropertyDescriptor(Object.prototype,
__proto__).set if anyone can always use __proto__ to change the chain ?
I don't understand this poisoning ... I don't see any advantage, only
problems if some library would like to drop __proto__ and use in edge
On Mon, Apr 22, 2013 at 1:15 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
We don't currently have the concept of an object belonging to a realm.
Functions have a realm association, but not non-function object.
The current idea on how to solve the security issue with weak references
(and
Ok, I have read more messages on this thread and looked at some of the
supporting material that has been pointed at. The notes from the last
meeting record a conversation before I arrived, and I'm not quite clear
what it says was agreed on. In any case, I think the primary goals should
be and seem
OMG. I omitted the most important constraint:
On Mon, Apr 22, 2013 at 8:11 PM, Mark S. Miller erig...@google.com wrote:
[...]
* Normal objects have a [[SetPrototype]] method like
function [[SetPrototype]] (newValue) {
// normal checks for proto acceptability
// * either
At least this one is minor:
On Mon, Apr 22, 2013 at 8:11 PM, Mark S. Miller erig...@google.com wrote:
[...]
{ getter: [[ProtoGetter]], setter: [[ProtoSetter]], enumerable: false,
configurable: true }
Should be
{ get: [[ProtoGetter]], set: [[ProtoSetter]], enumerable: false,
Hi Axel,
Le 21/04/2013 01:37, Axel Rauschmayer a écrit :
__proto__ can be globally switched off by deleting
Object.prototype.__proto__. I'm assuming that that is useful for
security-related applications (Caja et al.). But I'm wondering:
doesn't that go too far? I'm seeing three ways of using
On Apr 20, 2013, at 4:37 PM, Axel Rauschmayer wrote:
__proto__ can be globally switched off by deleting
Object.prototype.__proto__. I’m assuming that that is useful for
security-related applications (Caja et al.). But I’m wondering: doesn’t that
go too far? I’m seeing three ways of using
On Apr 21, 2013, at 5:22 AM, David Bruant wrote:
Hi Axel,
Le 21/04/2013 01:37, Axel Rauschmayer a écrit :
__proto__ can be globally switched off by deleting
Object.prototype.__proto__. I’m assuming that that is useful for
security-related applications (Caja et al.). But I’m wondering:
Allen Wirfs-Brock wrote:
On Apr 21, 2013, at 5:22 AM, David Bruant wrote:
Hi Axel,
Le 21/04/2013 01:37, Axel Rauschmayer a écrit :
__proto__ can be globally switched off by deleting
Object.prototype.__proto__. I’m assuming that that is useful for
security-related applications (Caja et al.).
On Apr 21, 2013, at 8:55 AM, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
Deleting Object.prototype.__proto__ will not be be specified as disabling
{__proto__: foo}.
Was that what we'd agreed to? I hadn't remembered that. I don't like it because
it's special-case syntax, but I can also
you can hot-swap the chain, something Object.create() cannot do so it is
much more powerful, unless things changed that much lately ...
On Sun, Apr 21, 2013 at 11:03 AM, David Herman dher...@mozilla.com wrote:
On Apr 21, 2013, at 8:55 AM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
David Herman wrote:
On Apr 21, 2013, at 8:55 AM, Allen Wirfs-Brockal...@wirfs-brock.com wrote:
Deleting Object.prototype.__proto__ will not be be specified as disabling
{__proto__: foo}.
Was that what we'd agreed to?
I think what Allen means is, whether or not there's a magic
On Apr 21, 2013, at 11:03 AM, David Herman wrote:
On Apr 21, 2013, at 8:55 AM, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
Deleting Object.prototype.__proto__ will not be be specified as disabling
{__proto__: foo}.
Was that what we'd agreed to? I hadn't remembered that. I don't like
Allen Wirfs-Brock wrote:
On Apr 21, 2013, at 10:03 AM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
This isn't what we seemed to agree on at past TC39 meetings.
It's also not what the engines trying to converge on ES6 semantics have
implemented.
It's not clear to me, yet what convergence we
On Apr 21, 2013, at 11:12 AM, Brendan Eich wrote:
David Herman wrote:
On Apr 21, 2013, at 8:55 AM, Allen Wirfs-Brockal...@wirfs-brock.com wrote:
Deleting Object.prototype.__proto__ will not be be specified as disabling
{__proto__: foo}.
Was that what we'd agreed to?
I think what
Allen Wirfs-Brock wrote:
On Apr 21, 2013, at 11:12 AM, Brendan Eich wrote:
David Herman wrote:
On Apr 21, 2013, at 8:55 AM, Allen Wirfs-Brockal...@wirfs-brock.com wrote:
Deleting Object.prototype.__proto__ will not be be specified as disabling
{__proto__: foo}.
Was that what we'd agreed
Brendan Eich wrote:
Allen Wirfs-Brock wrote:
On Apr 21, 2013, at 11:12 AM, Brendan Eich wrote:
David Herman wrote:
On Apr 21, 2013, at 8:55 AM, Allen
Wirfs-Brockal...@wirfs-brock.com wrote:
Deleting Object.prototype.__proto__ will not be be specified as
disabling {__proto__: foo}.
Was
V8 already poisons when getOwnPropertyDescriptor has a setter and this
setters is the __proto__ one:
https://code.google.com/p/v8/source/browse/trunk/src/v8natives.js#390
This means V8 always throws and does not preserve the same realm, if I
understand what that means:
On Apr 21, 2013, at 11:53 AM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
...
This is specified by ES5, already.
Doesn't matter because what ES5 specifies is already incompatible with web
reality when the property name is __proto__.
No. Browsers implementing ES5 and de-facto
Allen that's correct/expected ... as __proto__ is own in the
Object.prototype only or am I missing something?
On Sun, Apr 21, 2013 at 12:21 PM, Allen Wirfs-Brock
al...@wirfs-brock.comwrote:
On Apr 21, 2013, at 11:53 AM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
...
This is specified
On Apr 21, 2013, at 12:05 PM, Brendan Eich wrote:
What I mean is that:
let obj = {__proto__: null}
will always create an object whose [[Prototype]]
Didn't you mean an object whose property named '__proto__' here?
is null. Regardless of whether or not anybody has done:
delete
Allen Wirfs-Brock wrote:
On Apr 21, 2013, at 12:05 PM, Brendan Eich wrote:
What I mean is that:
let obj = {__proto__: null}
will always create an object whose [[Prototype]]
Didn't you mean an object whose property named '__proto__' here?
is null. Regardless of whether or not anybody
1 - 100 of 140 matches
Mail list logo
