RE: Object.freezing proxies should freeze or throw?

“Testing an object to see if it is a Proxy is not an operation that is available to ES code via the MOP” By the way, why such a test is not available? I think that everything should be testable, but it’s not the case actually. ___ es-discuss

Re: Object.freezing proxies should freeze or throw?

Tom, I.m not sure that I agree with your conclusion and your fix. I agree that there doesn’t appear to be a bug with the implementation of any of the currently specified proxy invariant checks and hence the problem is internal to Object.freeze. But Object.freeze is not a “MOP level”

Re: Object.freezing proxies should freeze or throw?

Hi Raul, yes it would. The invariants apply to all objects. If someone would like to write up the spec bug and fix, I'll happily represent and advance it at upcoming meetings. On Sun, Aug 7, 2016 at 6:49 AM, Raul-Sebastian Mihăilă < raul.miha...@gmail.com> wrote: > Would be a good idea to do

Re: Object.freezing proxies should freeze or throw?

Would be a good idea to do the test for any kind of exotic objects (including host defined ones), not only for proxies? On Sun, Aug 7, 2016 at 4:33 PM, Tom Van Cutsem wrote: > Good catch. This appears to be a genuine spec bug. > > First, I thought that the problem simply was

Re: Object.freezing proxies should freeze or throw?

Good catch. This appears to be a genuine spec bug. First, I thought that the problem simply was due to sloppy-mode silent failures, as a call to Object.isFrozen revealed that the proxy is not actually frozen after the call to Object.freeze. When your script is run in strict mode, it fails: on

Re: How to refer to the current prototype of a class.

> Having such a keyword for convenience may also encourage class designers to avoid the [Fragile Base Class Problem]( https://www.cs.cmu.edu/~aldrich/papers/selective-open-recursion.pdf). Maybe not to avoid the fragile base class problem per se, but it would be easier to express using the current