On Dec 18, 2012, at 9:08 AM, Brendan Eich wrote: > Mark S. Miller wrote: >> That could work, but because of its complexity, I'm leaning back towards the >> "configurable data property that refuses to be configured" approach. Is >> there a problem with that? It self-hosts fine. > > Certainly this is the simplest solution. It has a slight smell, but no worse > than the others'! >
I'm really bothered by this concept. It seems to be saying: For my important use cases, I must be able to depend upon the meaning of [[Configurable]]: false. So implementation must take all measures necessary to ensure that meaning. However, I don't care about other use cases that might depend upon the meaning of [[Configurable]]: true. I think its fine that an implementation lies and says that an object is configurable when it really isn't. This really seems like a double standard. Integrity issue are important, and in some cases may need to be given special consideration, but we need to consider the full spectrum of use cases. Regarding simplicity. I don't really see it. For example, we presumably still want global object bindings introduced via var to not be deletable via delete (unless they were introduced using eval). How do we express the link between the semantic of var and delete if we can't use [[DefineOwnProperty]], [[GetOwnProperty]] and the [[Configurable]] attribute . Instead we have to define some new mechanism/state to establish this relationship [1]. More generally, if we forbid certain host object from having [[Configurable]]: false properties yet we also need to have some properties be non-deletable then we will need a new mechanism that allows that to be expressed and specified. If we are only talking about the Global Object, we can probably accommodate almost anything by defining it as a special kind of exotic object. We already have special case handling for declarations and identifier resolution involving it. But once we're in the space of arbitrary exotic objects I think we should be very careful about trying to identify and enforce additional invariants. Allen [1] https://mail.mozilla.org/pipermail/es-discuss/2012-December/027196.html > /be > _______________________________________________ > 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
