Interaction with other proposals and use cases

dead-claudia commented 5 years ago

I know of a couple points where this could integrate with:

Binary JS necessarily does not have any source to return from toString. Should this provide some common infrastructure for that to streamline the two? (Not proposing these two should be merged, just informed by one another.)
It should be possible for an implementation to optionally require all sources to be parsed with hidden function implementations, for memory reasons. Two use cases of this that come to mind would include embedded IoT (think: Moddable Zero, Tessel) and cloud function-as-a-service services (think: AWS Lambda, Netlify Functions, Cloudflare workers), both situations where memory usage comes at a premium. Here's two specific points of reference: Moddable's XS already censors Function.prototype.toString as a deliberate spec violation, and JerryScript, which supports ES5 only, does similar.

I feel these two scenarios should probably be considered to some extent and maybe appropriate hooks made. The infrastructure to do this already generally exists with this proposal, so I'm just suggesting that in addition to allowing source-controlled function hiding, it should also lay a common groundwork for other reasons you shouldn't/can't have function sources exposed.

ljharb commented 5 years ago

Engines already can opt to omit all source from any or all functions, unrelated to this proposal - there’s an implementation hook.

dead-claudia commented 5 years ago

Where? If so, I can close this issue. (I assume you're referring to somewhere in the spec.)

ljharb commented 5 years ago

https://tc39.github.io/ecma262/#sec-hosthassourcetextavailable

dead-claudia commented 5 years ago

Okay, then this is probably moot then.

tc39 / proposal-function-implementation-hiding

Interaction with other proposals and use cases #20