Where is it specified that new objects are empty, if it is?
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, enumerable: false, configurable: false}
Oh come on! :-P
The two results are clearly non-conformant, in that gOPN and gOPD should be consistent with each other. However, the problem that I'm wanting to record accurately is the fact that Object.create(null) has (however inconsistently) any properties at all (thus interfering with table-like uses).
ES6 will specify proto as "own" and configurable in Object.prototype. Whether magic data or accessor with censored or poisoned getter and setter I'm not sure at the moment, but the above will definitely not conform to ES6.
15.2.3.5 Object.create refers to 15.2.2.1 which specifies “a newly created native ECMAScript object”. Where is the initial state of the collection of properties of a “newly created” object specified? (8.6 defining the Object type doesn't say anything about the existence of non-internal properties.)
Whoa, spec hole. Allen?
(I recognize that this behavior may well be a deliberate variance to reconcile proto and ES5/ES6. This is not a complaint; this is a request to consult spec-lawyers.)
Ok, whew. Sorry for lawyering,
V8 now uses an accessor on Object.prototype.
On 16 March 2013 00:00, Kevin Reid <kpreid at google.com> 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, enumerable: false, configurable: false}
That seems to be the old odd behaviour, not the new. On V8 trunk you get 'undefined' for the latter.
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.
Andreas Rossberg wrote:
On 16 March 2013 00:00, Kevin Reid<kpreid at google.com> 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, enumerable: false, configurable: false}
That seems to be the old odd behaviour, not the new. On V8 trunk you get 'undefined' for the latter.
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 reflection, or returning poison-pill getter and setter?
On 18 March 2013 17:43, Brendan Eich <brendan at mozilla.com> 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 reflection, or returning poison-pill getter and setter?
Currently neither -- because proto is a magic data property, you cannot extract any getter/setter. When you read the property descriptor, though, its .value is null.
(Also, a funny side effect of the magic is that making that property non-writable will prevent you from setting prototypes via proto.)
Andreas Rossberg wrote:
On 18 March 2013 17:43, Brendan Eich<brendan at mozilla.com> 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 reflection, or returning poison-pill getter and setter?
Currently neither
Right, I meant when you make it an accessor.
On 18 March 2013 18:18, Brendan Eich <brendan at mozilla.com> wrote:
Andreas Rossberg wrote:
On 18 March 2013 17:43, Brendan Eich<brendan at mozilla.com> 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 reflection, or returning poison-pill getter and setter?
Currently neither
Right, I meant when you make it an accessor.
We plan to follow what the draft spec will say once it's there ;). IIRC we agreed on poison pill last time round.
I'm doing a little maintenance on SES. Chrome has recently added a new odd behavior:
Object {value: null, writable: true, enumerable: false, configurable: false}
The two results are clearly non-conformant, in that gOPN and gOPD should be consistent with each other. However, the problem that I'm wanting to record accurately is the fact that Object.create(null) has (however inconsistently) any properties at all (thus interfering with table-like uses).
15.2.3.5 Object.create refers to 15.2.2.1 which specifies “a newly created native ECMAScript object”. Where is the initial state of the collection of properties of a “newly created” object specified? (8.6 defining the Object type doesn't say anything about the existence of non-internal properties.)
(I recognize that this behavior may well be a deliberate variance to reconcile proto and ES5/ES6. This is not a complaint; this is a request to consult spec-lawyers.)
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, enumerable: false, configurable: false} The two results are clearly non-conformant, in that gOPN and gOPD should be consistent with each other. However, the problem that I'm wanting to record accurately is the fact that Object.create(null) has (however inconsistently) any properties at all (thus interfering with table-like uses). 15.2.3.5 Object.create refers to 15.2.2.1 which specifies “a newly created native ECMAScript object”. Where is the initial state of the collection of properties of a “newly created” object specified? (8.6 defining the Object type doesn't say anything about the existence of non-internal properties.) (I recognize that this behavior may well be a deliberate variance to reconcile __proto__ and ES5/ES6. This is not a complaint; this is a request to consult spec-lawyers.)