ToPropertyDescriptor, [[HasProperty]], & [[HasOwnProperty]]
I agree with you that this would be a much better design, but it would break backwards compatibility with ES5, no? Minor nitpick: I guess you mean to say that ToPropertyDescriptor should use the abstract operation HasOwnProperty, not [[HasOwnProperty]]...
I agree with you that this would be a much better design, but it would break backwards compatibility with ES5, no?
There have been other changes to the spec that are technically back-compat breaking like Object.keys('x') no longer throwing an error. I think this change would benefit developers as the case seems to be devs getting bitten by the current behavior.
Minor nitpick: I guess you mean to say that ToPropertyDescriptor should use the abstract operation HasOwnProperty, not [[HasOwnProperty]]
Sure, I'll switch to ES6y terms. Yes, I mean the abstract operation HasOwnProperty.
that does not save you from errors when Object.prototype.get = function(){}
since writable
and get/set
cannot coexist in a descriptor
... a safe approach is to create var descriptor = Object.create(null);
and then set its value
later on before assignment.
I remember early discussion with Allen and Brendan about this, the solution
was a hybrid [[HasNonObjectProperty]] check so that everything inherited
except Object.prototype
was considered ... although:
- we have two kind of descriptors, accessors and value descriptors. I
don't know who would create classes in order to inherit just a couple of
propeties ... like
new WritableButNotConfigurable(value)
? Has anyone ever seen a piece of code like that? - accordingly to point one, descriptors should rather change into
null
objects ASAP and stop this descriptor minefield I am pretty sure nobody expect or desire to work like that
Changing that part of the specs iw say easier than defining a new [[HasNonObjectProperty]] pattern, IMO
My 2 cents
iw<=>say ... "is way"
OK, hasOwnProperty per descriptor would work too ... probably even easier as spec change than having all null objects
+1 to that
On May 8, 2014, at 1:25 PM, John-David Dalton wrote:
ES6 additions like Object.assign use [[OwnPropertyKeys]] for getting the keys of
source
objects. This helps avoid the method gotchas faced by developers previously with things likeObject.prototype.writable = true
andObject.defineProperty(o, 'foo', { value: 'bar' })
.See developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/defineProperty#Description (bottom of section)
"Bear in mind that these options are not necessarily own properties so, if inherited, will be considered too. In order to ensure these defaults are preserved you might freeze the Object.prototype upfront, specify all options explicitly, or point to null as proto property."
It's the reason I pre-populate my descriptor attributes with false even though false is the default. See lodash/lodash/blob/2.4.1/dist/lodash.js#L112-L117
With methods like Object.assign using [[OwnPropertyKeys]] does it make sense to make things like ToPropertyDescriptor use [[HasOwnProperty]] too. I think it would be a win for consistency and dev use.
Thoughts?
some prior discussions on this topic (or related): esdiscuss.org/topic/nuking-misleading-properties-in-object-getownpropertydescriptor, www.esdiscuss.org/topic/object-prototype-get-bye-bye-object-defineproperty, esdiscuss.org/topic/property
Thanks for the discussion links, Allen. I'm I reading it right that there was no concrete resolution to the issue?
On May 8, 2014, at 4:05 PM, John-David Dalton wrote:
Thanks for the discussion links, Allen. I'm I reading it right that there was no concrete resolution to the issue?
Right, nothing concrete came out of it so won't happen for ES6.
Post-ES6 is always possible.
Is Post-ES6 up for discussion? Should I create a spec bug for tracking this?
Rock, will do.
just wrote this down ... it takes an eye blink to agree with and adopt even in ES6, IMHO gist.github.com/WebReflection/48aecb771e61e8a3e168
also, on top of this ... I'd like to add the fact that es5-sham, the drop in everyone thinks is cool to use to support old browsers not compatible with ES5, is entirely based on own properties since ever: es-shims/es5-shim/blob/master/es5-sham.js#L310
the owns definition in that scope: es-shims/es5-shim/blob/master/es5-sham.js#L28
I've never filed a bug against it, because as it is it has been just safer for "the old" Web
Best
P.S. we are 1 year later on fixing this :-(
just for record sake, I've re-explained what's the issue here in a node.js related thread: joyent/node#7587
Best
ES6 additions like Object.assign use [[OwnPropertyKeys]] for getting the keys of
source
objects. This helps avoid the method gotchas faced by developers previously with things likeObject.prototype.writable = true
andObject.defineProperty(o, 'foo', { value: 'bar' })
.See developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/defineProperty#Description (bottom of section)
"Bear in mind that these options are not necessarily own properties so, if inherited, will be considered too. In order to ensure these defaults are preserved you might freeze the Object.prototype upfront, specify all options explicitly, or point to null as proto property."
It's the reason I pre-populate my descriptor attributes with false even though false is the default. See lodash/lodash/blob/2.4.1/dist/lodash.js#L112-L117
With methods like Object.assign using [[OwnPropertyKeys]] does it make sense to make things like ToPropertyDescriptor use [[HasOwnProperty]] too. I think it would be a win for consistency and dev use.
Thoughts?