Open claudepache opened 4 years ago
Given that it’s observable from outside wrt arguments/caller, it makes sense to me for any function of any origin.
@ljharb If a function is not censored for .caller and .arguments, then it is non-strict. But the implication goes only in one direction, so it cannot be used as a criterion for distinguishing between strict and non-strict. For instance, in JSC (and possibly other engines), it is impossible to distinguish between a non-strict generator function and a strict generator function using only .arguments and .caller.
I have guessed that there could have been some relation with the behaviour of .caller and .arguments, but, as I said, it didn’t suggested to me any reasonable definition of “strict”.
I had a misunderstood about strict. I thought all functions are strict or nonstrict. I thought it is binary.
Now I know the "strict" only used in ECMAScript functions. With this nonbinary meaning, any words of "strict function" or "non-string function" will become a dangerous trap.
As you can see, we fall into this trap (.caller must not be a strict function, the editor might think that equals to "loose" functions), I think it's better to specify the "strictness" of non-ECMAScript functions so the "strict/nonstrict" can be a binary relation and never fall in to bug like this case.
e.g. All built-in function will be treated as strict (in the comparison like "must be strict" or "must not be strict") The bound function (returned by f.bind()) is strict when f is strict, vice verse.
I also see it more as, “is this function sloppy? If i can’t determine that it is, including by looking at the code, then it’s strict”
Ok, I’m still unconvinced, but let me go to the point. Why do we want a distinction between “strict” and “non-strict” non-ECMAScript function? Is it just for restrictions around .caller and .arguments, or are there other uses?
Why do we care if a function is non-ECMAScript or not? ECMAScript functions may or may not have source available, so I'm not sure why it matters.
@ljharb What I care about, is that the notion of “strict function” be sound with a clear purpose.
There is not many use case of strict
or non-strict
and it might not increase in the future. So another way is to review all the current use cases of strict
and non-strict
to see if there is any that uses the term that not reflecting the design purpose (and might cause a bug).
ECMAScript functions may or may not have source available
@ljharb I am not sure what that mean. Isn't ECMAScript functions always have ECMAScript code by definition?
@hax function () {}.bind()
is an ecmascript function that does not have source text available.
@ljharb As I understand bound functions are not ECMAScript functions.
ok, fair enough - then both of the implementation hiding proposal, or the Function.prototype.toString source hook that's already in the spec, can allow ECMAScript functions without available source text ¯\_(ツ)_/¯
@ljharb They only hide source for the 3rd party libraries in runtime, seems no relation to engines?
Engines have source text available for their c++ functions, it’s just not JS code.
The issue of availability of source code is off-topic; it is orthogonal both to the issue of strictness and to the issue of .caller and .arguments.
@erights I have mentioned my idea here https://github.com/Jack-Works/proposal-strict-built-in-functions/issues/3#issuecomment-577789819
I think it's better to specify every kind of non-ES functions case by case so .bind
can specify its result as a non-strict function.
So on this purpose maybe it no longer gets covered by Claude's proposal. Maybe we should re-add it as a separate work?
First, we made stage 1. Congrats to us!
What is the current behavior of bound functions? Can someone do these same tests across browsers? Thanks.
@erights can you give me some code? i can run it in eshost.
@claudepache do you have the code you tested with?
To be clear, what made it to stage 1 is the combination of the two proposals.
Le 6 févr. 2020 à 03:33, Mark S. Miller notifications@github.com a écrit :
First, we made stage 1. Congrats to us!
What is the current behavior of bound functions? Can someone do these same tests across browsers? Thanks.
See https://github.com/claudepache/es-legacy-function-reflection/issues/6#issuecomment-575162851
—Claude
try {
print((function(){}).caller);
} catch (e) { print(e); }
try {
print((function(){}).bind().caller);
} catch (e) { print(e); }
yields:
#### ch
null
TypeError: 'arguments', 'callee' and 'caller' are restricted function properties and cannot be accessed in this context
#### Chakra
null
TypeError: 'arguments', 'callee' and 'caller' are restricted function properties and cannot be accessed in this context
#### JavaScriptCore
null
TypeError: 'arguments', 'callee', and 'caller' cannot be accessed in this context.
#### jsc
null
TypeError: 'arguments', 'callee', and 'caller' cannot be accessed in this context.
#### sm
null
TypeError: 'caller', 'callee', and 'arguments' properties may not be accessed on strict mode functions or the arguments objects for calls to them
#### SpiderMonkey
null
TypeError: 'caller', 'callee', and 'arguments' properties may not be accessed on strict mode functions or the arguments objects for calls to them
#### v8
null
TypeError: 'caller', 'callee', and 'arguments' properties may not be accessed on strict mode functions or the arguments objects for calls to them
#### V8
null
TypeError: 'caller', 'callee', and 'arguments' properties may not be accessed on strict mode functions or the arguments objects for calls to them
#### V8 --harmony
null
TypeError: 'caller', 'callee', and 'arguments' properties may not be accessed on strict mode functions or the arguments objects for calls to them
#### xs
undefined
TypeError: ?: strict mode
Le 6 févr. 2020 à 03:57, Mark S. Miller notifications@github.com a écrit :
@claudepache do you have the code you tested with?
Here are some tests:
https://github.com/claudepache/es-legacy-function-reflection/blob/master/simple-tests.js
For bound functions and proxies, you may need to carefully follow their semantics in order to correctly interpret the results.
For bound functions and proxies, you may need to carefully follow their semantics in order to correctly interpret the results.
More precisely:
proxy.caller
, one of the following things will happen: either the “get” handler will be triggered, or the property lookup will be made on [[ProxyTarget]] but with the same “receiver” as the original lookup. In the latter case, the result will depend on whether .caller is implemented as a magic data property (the receiver will be ignored) or as an accessor (the receiver will be taken into account).
By definition, a strict function, resp. a non-strict function, is an ECMAScript function whose code is in strict mode code, resp. non-strict mode code. Such a definition makes sense only for ECMAScript functions.
But you seem to give some other meaning for “strict” that would apply to non-ECMAScript functions (as builtin functions are, in practice, most often non-ECMAScript). I tried to think of some reasonable definition, but I couldn’t find one.
So, what do you mean exactly by “strict function”?