Observing whether a function is strict
On Thu, May 26, 2016 at 9:48 AM, Claude Pache <claude.pache at gmail.com> wrote:
I was wondering whether there is a way to observe whether a given random function is strict (or sloppy, or neither). […] Are there other ways? (If not, I find it somewhat unfortunate that only such nonstandard features leak this information.)
I smell a proposal for Reflect.isStrict in the making…
Le 26 mai 2016 à 09:57, Mathias Bynens <mathiasb at opera.com> a écrit :
On Thu, May 26, 2016 at 9:48 AM, Claude Pache <claude.pache at gmail.com> wrote:
I was wondering whether there is a way to observe whether a given random function is strict (or sloppy, or neither). […] Are there other ways? (If not, I find it somewhat unfortunate that only such nonstandard features leak this information.)
I smell a proposal for
Reflect.isStrictin the making…
(To be clear, I would be strongly opposed to such a proposal: Being strict or not is an implementation detail that the consumer need not know.)
I was under the impression that strict mode is a (temporary) workaround to get rid of unwanted bad parts of the language without instantly breaking anything. The long term question thus should be: do we have a timeline on the final removal of non-strict behavior from the language, and establish the "strict mode" as the one and only standard behavior. If so, then introducing any additional language feature to help detecting strict/non-strict is certainly not ideal.
As a side note - if we're gonna have Traits in ES I'd really like to see
something like Scala's class CollegeStudent extends Student with Worker with Underpaid with Young, but the valuable with keyword is currently
occupied by a phantom from the language's rugged past. I'd really like to
see these ghosts from the past being removed from the spec once and for all
instead of being hidden behind some doors with a "DONT TOUCH" sign on it.
I would be mostly okay if sloppy mode goes away. The only use case I have now for it is for accessing the global in a platform independent manner, but the System.global proposal eliminates this need. I write all code in strict mode now, so I only see likely performance benefits from completely ditching sloppy. Also, ES6 modules are in strict mode.
As for code generation, which some libraries use, they'll probably the the
most affected. Template libraries usually use with statements in sloppy
mode to simplify the work in creating the functions. The only other methods
are to either restrict the format of the interpolations or require/assume
an argument with a specific name.
Le 26 mai 2016 à 10:43, G. Kay Lee <balancetraveller+es-discuss at gmail.com> a écrit :
I was under the impression that strict mode is a (temporary) workaround to get rid of unwanted bad parts of the language without instantly breaking anything. The long term question thus should be: do we have a timeline on the final removal of non-strict behavior from the language, and establish the "strict mode" as the one and only standard behavior. If so, then introducing any additional language feature to help detecting strict/non-strict is certainly not ideal.
AFAIK, there is no plan to remove non-strict mode.
And to be clear about my intentions, what I have in the back of my head was certainly not "introducing any additional language feature to help detecting strict/non-strict" (yuck!), but whether it makes sense to think about a possible way to remove that leak from Function#arguments and Function#caller. But it would be premature to consider that issue without at least an answer to my original question: Are there other ways...?
On Thu, May 26, 2016 at 11:25 AM, Claude Pache <claude.pache at gmail.com>
wrote:
Le 26 mai 2016 à 10:43, G. Kay Lee < balancetraveller+es-discuss at gmail.com> a écrit :
I was under the impression that strict mode is a (temporary) workaround to get rid of unwanted bad parts of the language without instantly breaking anything. The long term question thus should be: do we have a timeline on the final removal of non-strict behavior from the language, and establish the "strict mode" as the one and only standard behavior. If so, then introducing any additional language feature to help detecting strict/non-strict is certainly not ideal.
AFAIK, there is no plan to remove non-strict mode.
And to be clear about my intentions, what I have in the back of my head was certainly not "introducing any additional language feature to help detecting strict/non-strict" (yuck!), but whether it makes sense to think about a possible way to remove that leak from
Function#argumentsandFunction#caller. But it would be premature to consider that issue without at least an answer to my original question: Are there other ways...?
Hi Claude, what do you mean by "remove that leak"? Hypothetically, let's say you had such a test and that it was reliable. How would you use it remove the leak? (This is probably also the best way to clarify what precisely you mean by removing the leak.)
On Thu, May 26, 2016 at 1:23 PM, Mark S. Miller <erights at google.com> wrote:
On Thu, May 26, 2016 at 11:25 AM, Claude Pache <claude.pache at gmail.com> wrote:
Le 26 mai 2016 à 10:43, G. Kay Lee < balancetraveller+es-discuss at gmail.com> a écrit :
I was under the impression that strict mode is a (temporary) workaround to get rid of unwanted bad parts of the language without instantly breaking anything. The long term question thus should be: do we have a timeline on the final removal of non-strict behavior from the language, and establish the "strict mode" as the one and only standard behavior. If so, then introducing any additional language feature to help detecting strict/non-strict is certainly not ideal.
AFAIK, there is no plan to remove non-strict mode.
There are indeed no plans to remove sloppy mode. Fortunately, the desire to make new features available in sloppy mode is waning. Sloppy mode should be seen only as an ES3 compatibility mode. It is unfortunate that we were not able to convince the committee not to extend new ES2015 features to sloppy mode. The result has cost both implementors and users. It cost implementors a substantial amount of extra work. (In side conversations I heard shockingly high estimates.) It hurt users by giving extra life to sloppy mode. None of this was needed for compat. The only compat requirement at the time was not to break pre-ES2015 sloppy code. Syntactically, that is essentially identical to ES3.
Hopefully we can avoid repeating this mistake moving forward from here. Let sloppy mode remain where it is while the rest of the language moves forward.
Le 26 mai 2016 à 13:23, Mark S. Miller <erights at google.com> a écrit :
On Thu, May 26, 2016 at 11:25 AM, Claude Pache <claude.pache at gmail.com <mailto:claude.pache at gmail.com>> wrote:
Le 26 mai 2016 à 10:43, G. Kay Lee <balancetraveller+es-discuss at gmail.com <mailto:balancetraveller%2Bes-discuss at gmail.com>> a écrit :
I was under the impression that strict mode is a (temporary) workaround to get rid of unwanted bad parts of the language without instantly breaking anything. The long term question thus should be: do we have a timeline on the final removal of non-strict behavior from the language, and establish the "strict mode" as the one and only standard behavior. If so, then introducing any additional language feature to help detecting strict/non-strict is certainly not ideal.
AFAIK, there is no plan to remove non-strict mode.
And to be clear about my intentions, what I have in the back of my head was certainly not "introducing any additional language feature to help detecting strict/non-strict" (yuck!), but whether it makes sense to think about a possible way to remove that leak from
Function#argumentsandFunction#caller. But it would be premature to consider that issue without at least an answer to my original question: Are there other ways...?Hi Claude, what do you mean by "remove that leak"? Hypothetically, let's say you had such a test and that it was reliable. How would you use it remove the leak? (This is probably also the best way to clarify what precisely you mean by removing the leak.)
Maybe that "leak", namely observing whether a function is strict, is not something to care about.
But here is what I think to be a possible way to remove it: Because Function#arguments and Function#caller do return null for sloppy functions in some circumstances (namely, when the function is not found in the call stack), let them always return null for non-sloppy functions.
I don't get it. What is being removed? What purpose does this accomplish?
Le 26 mai 2016 à 17:02, Mark Miller <erights at gmail.com> a écrit :
I don't get it. What is being removed?
A way to observe (almost surely?) that a given ECMAScript function is strict.
What purpose does this accomplish?
As I've said, maybe nothing to care about. That strange capability of Function#arguments just presented itself to my mind, and I really didn’t thought whether that has any consequence.
I was wondering whether there is a way to observe whether a given random function is strict (or sloppy, or neither).
Apart from flawed guess based on
Function#toString(flawed, because it could only detect "use strict" prologue, which is insufficient), the only way I see is to observe whether the nonstandard, deprecated and unbelovedFunction#argumentsandFunction#callerfunctionalities throw an error. Are there other ways. (If not, I find it somewhat unfortunate that only such nonstandard features leak this information.)