noSuchMethod: "funargs" + "invoke-only-phantoms"

Dmitry Soshnikov dmitry.soshnikov at
Tue Dec 27 04:19:04 PST 2011

(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 (, step 3.a cleary states that
the property is removed.


On Wed, Dec 21, 2011 at 11:53 PM, Tom Van Cutsem < at> wrote:

> 2011/12/21 Dmitry Soshnikov <dmitry.soshnikov at>
>>  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: <
> Cheers,
> Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list