Re: Bug: Reflect.ownKeys(function() {}) differs in V8 strict mode than other cases

> So if all my code is in strict mode, and I get a non-strict code function to > shadow as Tom and I were talking about in another thread... how do I even > test for that if my code is either consistently strict or consistently > non-strict? Don't check that. The target could have other

Re: Bug: Reflect.ownKeys(function() {}) differs in V8 strict mode than other cases

Ugh!! It's a trap! (In the Star Wars sense, not the proxy sense.) So if all my code is in strict mode, and I get a non-strict code function to shadow as Tom and I were talking about in another thread... how do I even test for that if my code is either consistently strict or consistently

Re: Bug: Reflect.ownKeys(function() {}) differs in V8 strict mode than other cases

Ah, my bad, you’re right — they only expose the accessors on the prototype, so they’re in the clear. But yeah, there’s no requirement one way or the other (other than re: web compat) for the properties being there in sloppy mode. > On Sep 5, 2016, at 9:20 PM, Oriol Bugzilla

Re: Re: Bug: Reflect.ownKeys(function() {}) differs in V8 strict mode than other cases

Web compat enforces adding them in sloppy mode. My understanding of what he’s saying is that V8 “incorrectly” omits these own properties from strict functions, which is correct per spec. signature.asc Description: Message signed with OpenPGP using GPGMail

Re: Bug: Reflect.ownKeys(function() {}) differs in V8 strict mode than other cases

Besides those two, the only other reference to AddRestrictedFunctionProperties is < http://www.ecma-international.org/ecma-262/7.0/#sec-createintrinsics> step 12: 12. Perform AddRestrictedFunctionProperties

Re: Bug: Reflect.ownKeys(function() {}) differs in V8 strict mode than other cases

> Mozilla's approach violates ECMAScript's forbidden extensions and can't be > considered "correct" Why? The spec forbids adding "caller" or "arguments" in strict mode. I think it does not enforce adding them in sloppy mode. Chrome seems to add them only in sloppy mode, and Firefox to never

Re: Bug: Reflect.ownKeys(function() {}) differs in V8 strict mode than other cases

The part that matters here is in annex B: http://www.ecma-international.org/ecma-262/7.0/#sec-forbidden-extensions This forbids functions in strict code from having own properties "caller" or "arguments". Newer function kinds have these restrictions in sloppy mode. AddRestricted... adds the

Bug: Reflect.ownKeys(function() {}) differs in V8 strict mode than other cases

"use strict" function A() {} function B() {} window.onload = function() { let a = Reflect.ownKeys(A); let b = Reflect.ownKeys(B); document.getElementById("output").value = (a.includes("arguments") === b.includes("arguments")); } Mozilla Firefox reports

Re: Extended dot notation (pick notation) proposal

Hmm I gotta say I must have re-read that minimally extended dot notation proposal a few times and I just find the syntax confusing. I do like the idea of building a way of taking a portion of an object out of one object and into another but I don't think we need to provide additional syntax rules

Re: Extended dot notation (pick notation) proposal

TypeScript has a fair number of proposals aiming to address this (things like difference types, partial types, etc.), but in general, I find it just as easy to do it this way (which is easily checked): ```js const {toDate, fromDate, location, flavor} = this.state; const goodKeys = {toDate,

Re: Proxies and preventExtensions: how to avoid inconsistency in a membrane?

Is a proxy a valid proxy target? If that's the case, then the indirection should allow you to do what you're doing. The outer proxy could freeze and let the inner proxy know it shouldn't extend anything anymore, without actually freezing it. The inner proxy can handle the rest of the actual logic