Oops, misfire. The rest of that:
function shadow(obj, props) {
var ret = Object.create(obj);
for (var k in props)
ret[k] = props[k]
return ret;
}
// Elsewhere...
function defineSomeProps (obj) {
var defaults = { enumerable: true, writable: true, configurable:
true };
Object.defineProperties(obj, {
foo1: shadow(defaults, { value: 'bar1' })),
foo2: shadow(defaults, { value: 'bar2' })),
foo3: shadow(defaults, { value: 'bar3' })),
// etc...
});
}
If people have a generic shadow() function that creates an object and
copies properties to it (less verbosely than just using Object.create),
they could be tempted to use it to create ES3-style EWC properties.
On Thu, Dec 18, 2014 at 1:24 PM, Andy Earnshaw <andyearns...@gmail.com>
wrote:
>
> Can we be sure nobody's ever written something like this:
>
> function shadow(obj, props) {
> var ret = Object.create(obj);
> }
>
> On Thu, Dec 18, 2014 at 10:08 AM, Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
>> My main point is that everything you get from
>> `Object.getOwnPropertyDescriptor`, beside undefined or possible abrupt
>> errors, will have own properties.
>>
>> Even es5-shim/sham has been checking own properties for years [1] so I am
>> pretty confident nothing will break 'cause own properties is what
>> developers always expected and what they've always used despite specs.
>>
>> Again it's clear the world can live with these possibly inherited
>> descriptors properties but it feels very wrong on the practical level. Too
>> bad if there won't be ever a fix [2]
>>
>> [1] https://github.com/es-shims/es5-shim/issues/211#event-208821479 now
>> fixed
>>
>> [2] would a new Descriptor({ownproperties:"only"}) instance be ever
>> considered ?
>>
>>
>>
>> On Wed, Dec 17, 2014 at 8:37 PM, Allen Wirfs-Brock <al...@wirfs-brock.com
>> > wrote:
>>>
>>>
>>> On Dec 17, 2014, at 10:30 AM, Andrea Giammarchi wrote:
>>>
>>> Actually simplifying as proposal: does everyone agree that if a
>>> descriptor.[[Value]] is own property no further checks on inherited [[Get]]
>>> and [[Set]], or generally speaking Accessor Property related checks, should
>>> be made ?
>>>
>>> This would already fix the `Object.prototype.get` or `.set` case since I
>>> believe nobody ever used an inherited `value` property on purpose for
>>> descriptors ... or is it?
>>>
>>> It will keep `enumerable` and `writable` still potentially problematic
>>> but at least the following code would never fail:
>>>
>>> ```js
>>> Object.prototype.get = function () {}; Object.defineProperty(
>>> Object.prototype, 'toString', Object.getOwnPropertyDescriptor(
>>> Object.prototype, 'toString' ) );
>>>
>>> ```
>>>
>>> Thanks again for any sort of outcome (or clarification on when and if
>>> this will ever be fixed)
>>>
>>>
>>> I'm not sure what you are actually asking. All specified internal uses
>>> of property descriptor objets should pas through ToPropertyDescriptor (
>>> http://people.mozilla.org/~jorendorff/es6-draft.html#sec-topropertydescriptor
>>> ) which will throw if there is any conflict between get/set and own
>>> value/writable properties, regardless of whether they are own or inherited.
>>> (If you know of any uses of such descriptor object in the ES6 spec that
>>> don't do this validation, please file a bug).
>>>
>>> If you want to enforce the same semantics on you ES-level uses of
>>> descriptor objects you need to write a ES level implementation of the
>>> checks performed by ToPropertyDescriptor.
>>>
>>> I can see various ways we might improve the specified processing of
>>> property descriptor objects but those would generally be breaking changes
>>> and we would have to consider the possible impact of such changes before
>>> proceeding with them.
>>>
>>> Allen
>>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
