Discuss
  • Object.defineProperty with { get: undefined, set: undefined }

Object.defineProperty with { get: undefined, set: undefined }

# Jeff Walden (16 years ago)

Consider:

Object.defineProperty(obj, propname, { get: undefined, set: undefined });

Assuming obj has no property named by propname (whether it does or not is basically irrelevant to this question), the given expression apparently defines a property with this property descriptor:

{ [[Get]]: undefined, [[Set]]: undefined, [[Enumerable]]: false, [[Configurable]]: false }

The effect of getting such a property is to return undefined; setting it either has no effect or throws, depending on the precise code construct being used.

Anyway: what exactly is the meaning of a descriptor whose [[Get]] and [[Set]] fields are both |undefined|? Merely [[Set]] being |undefined| has a sensible meaning (readonly yet not necessarily constant property). Merely [[Get]] being |undefined| makes less sense -- one-way communication with an object via property setting, rather than by a method call? -- but okay, I can accept it as plausibly useful. But both [[Get]] and [[Set]] being undefined? I don't see the purpose or rationale behind it. Could someone enlighten me?

# Allen Wirfs-Brock (16 years ago)

Good one, I surprised that this has never come up before. I don't think there is anything intentional about the current design, it just fell out.

Such a property would have pretty much the same effect as Object.defineProperty(obj, propname, { value: undefined})

which creates a readonly, nonenumerable, nonconfigurable property whose value is undefined. There isn't much (if any, I need to look a litter deeper) real behavioral difference between such a data property and the equivalent accessor property except for what can be observed using Object.getOwnPropertyDescriptor.

I suppose we could put more conditions into [[DefineOwnProperty]] to reject accessors where both [[Get]] and [[Put]] are undefined. Do you think this is a significant issue? Is it an error that is likely to be made? [[DefineOwnPropoerty]] is already fairly complicated so unless there is some real hazard to allowing such properties I'm inclined to leave it as is.

# Mark S. Miller (16 years ago)

On Mon, Aug 3, 2009 at 6:39 PM, Allen Wirfs-Brock < Allen.Wirfs-Brock at microsoft.com> wrote:

Good one, I surprised that this has never come up before. I don't think there is anything intentional about the current design, it just fell out.

Such a property would have pretty much the same effect as Object.defineProperty(obj, propname, { value: undefined})

which creates a readonly, nonenumerable, nonconfigurable property whose value is undefined. There isn't much (if any, I need to look a litter deeper) real behavioral difference between such a data property and the equivalent accessor property except for what can be observed using Object.getOwnPropertyDescriptor.

I suppose we could put more conditions into [[DefineOwnProperty]] to reject accessors where both [[Get]] and [[Put]] are undefined. Do you think this is a significant issue? Is it an error that is likely to be made? [[DefineOwnPropoerty]] is already fairly complicated so unless there is some real hazard to allowing such properties I'm inclined to leave it as is.

I vote to leave it as is. Even if this setting doesn't make particular sense by itself, to prohibit it creates a special case. Symmetry and lack of hazard suggests allowing it. And given the last date...

# Jeff Walden (16 years ago)

On 3.8.09 18:39 , Allen Wirfs-Brock wrote:

Such a property would have pretty much the same effect as Object.defineProperty(obj, propname, { value: undefined})

which creates a readonly, nonenumerable, nonconfigurable property whose value is undefined. There isn't much (if any, I need to look a litter deeper) real behavioral difference between such a data property and the equivalent accessor property except for what can be observed using Object.getOwnPropertyDescriptor.

See the original email; in some contexts attempting to set the property will result in a TypeError being thrown. If it were simply equivalent to a data descriptor with value undefined, I probably would be much less concerned.

I suppose we could put more conditions into [[DefineOwnProperty]] to reject accessors where both [[Get]] and [[Put]] are undefined. Do you think this is a significant issue? Is it an error that is likely to be made? [[DefineOwnPropoerty]] is already fairly complicated so unless there is some real hazard to allowing such properties I'm inclined to leave it as is.

It's the throw-on-set behavior that I'm most worried about; I don't see how this particular flavor of property access is otherwise exposed, if this were to be forbidden. As a consequence, I don't see much reason to require implementations to have to support the extra complexity (nor users to defend against it, as presumably they would to reduce confusion), not when it could be avoided by adding a single step to ToPropertyDescriptor:

9.b. If desc.[[Get]] is undefined and desc.[[Set]] is undefined, then throw a TypeError exception.

# Mark S. Miller (16 years ago)

On Mon, Aug 10, 2009 at 7:07 PM, Jeff Walden <jwalden+es at mit.edu<jwalden%2Bes at mit.edu>

wrote:

On 3.8.09 18:39 , Allen Wirfs-Brock wrote:

Such a property would have pretty much the same effect as Object.defineProperty(obj, propname, { value: undefined})

which creates a readonly, nonenumerable, nonconfigurable property whose value is undefined. There isn't much (if any, I need to look a litter deeper) real behavioral difference between such a data property and the equivalent accessor property except for what can be observed using Object.getOwnPropertyDescriptor.

See the original email; in some contexts attempting to set the property will result in a TypeError being thrown. If it were simply equivalent to a data descriptor with value undefined, I probably would be much less concerned.

It is equivalent (modulo reflection) to a non-writable property with value undefined. Both throw when set from strict code. Neither throw when set from non-strict code.