didn't know about that custom possibility so yes, I guess we are OK here, thanks for the update.
br On Wed, Dec 19, 2012 at 5:54 AM, Tom Van Cutsem <[email protected]> wrote: > 2012/12/18 Mark S. Miller <[email protected]> > > I see no reason why this needs to be a reflected property. As to >> whether it is an exotic internal property or just prose, that is a >> specification expository issue for which I defer to Allen. But the >> spec only needs such extra state for the exotic global object. There's >> nothing general about it. >> > > The deeper issue pointed out by David here, I think, is that the triplet > {enumerable,writable,configurable} does not cover the entire possible space > of what one might want to express about the behavior of a property. > > If I understand correctly, the concrete case here is a property that > cannot be deleted (which is normally expressed as configurable:false), but > which should still remain configurable. > > I think it is unpractical and unwieldy to bake new attributes in to the ES > spec for every use case that pops up. > > However, in the context of proxies, we have previously talked about the > usefulness of allowing handlers to accept custom attributes in their > defineProperty trap and return custom attributes from their > getOwnPropertyDescriptor trap. > > By analogy, it might make sense for WebIDL-specified host objects to > return additional custom attributes to describe the behavior of special > properties that cannot be captured by {enumerable,configurable,writable}. > > The remaining "problem", of course, is that there is no standard semantics > for custom attributes. As mentioned by Allen in another thread, the only > solution here is for an exotic object to properly document its interface, > including what meaning it ascribes to any custom attributes it wishes to > report or accept. > > Cheers, > Tom >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
