(sorry, was in a small vacation, can't answer earlier) Yes, I'm perfectly aware about what host objects may do (there is even wide-spread phrase in JS community: "do not trust to host objects, they can do almost anything").
>From this viewpoint, if to treat these proxies as host objects, then in fact any of discussed broken invariants can be justified. But, I wanted to consider them from the view of casual JS objects. Regarding the "subtle difference", if to consider casual JS objects, then no, 8.12.7 (http://es5.github.com/#x8.12.7), step 3.a cleary states that the property is removed. Dmitry. On Wed, Dec 21, 2011 at 11:53 PM, Tom Van Cutsem <[email protected]> wrote: > 2011/12/21 Dmitry Soshnikov <[email protected]> > >> On 20.12.2011 17:00, Tom Van Cutsem wrote: >> >> You can (and probably should) advertise a virtual method as >> configurable:true. >> >> >> I can only `configurable: true', but as we said, to fix broken `delete' >> operator, we need to treat these virtual properties as non-configurable. We >> logically `return false' in `delete' trap and have to adjust >> `getOwnPropertyDescriptor' as well. >> > > This seems to be a persistent source of confusion about invariants in ES5: > The fact that a property is configurable:true _implies_ that it can be > successfully deleted is _not_ an ECMAScript invariant. > The ES5 spec only requires that configurable:false implies that the > property cannot successfully be deleted. > > The difference is subtle, but important. It would not surprise me if there > exist host objects that advertise their properties as configurable:true, > don't complain when you try to delete them, yet when you query the > properties again, they're still there. This is entirely within the bounds > of the ES5 spec. MarkM once explained the difference well: < > https://mail.mozilla.org/pipermail/es-discuss/2011-May/014150.html> > > Cheers, > Tom >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
