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

[Jeff Walden-6]

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?

Jeff
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[Allen Wirfs-Brock-2]

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.

Allen

>-----Original Message-----
>From: es-discuss-bounces@... [mailto:es-discuss-
>bounces@...] On Behalf Of Jeff Walden
>Sent: Monday, August 03, 2009 4:35 PM
>To: es-discuss@...
>Subject: Object.defineProperty with { get: undefined, set: undefined }
>
>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?
>
>Jeff
>_______________________________________________
>es-discuss mailing list
>es-discuss@...
>https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[Mark S. Miller-2]

On Mon, Aug 3, 2009 at 6:39 PM, Allen Wirfs-Brock <Allen.Wirfs-Brock@...> 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...

--
   Cheers,
   --MarkM

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[Jeff Walden-6]

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.

Jeff
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[Mark S. Miller-2]

On Mon, Aug 10, 2009 at 7:07 PM, Jeff Walden <jwalden%2Bes@...> 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.
 

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.

Jeff

_______________________________________________
es5-discuss mailing list
es5-discuss@...
https://mail.mozilla.org/listinfo/es5-discuss

--
   Cheers,
   --MarkM

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss