Question about GetBindingValue
Hello,
We found one "dead part" in ES5 and we're wondering whether we're missing something here. The question is about the 4th step in Section 10.2.1.2.4 GetBindingValue(N, S):
10.2.1.2.4 GetBindingValue(N,S) The concrete Environment Record method GetBindingValue for object environment records returns the value of its associated binding object's property whose name is the String value of the argument identifier N. The property should already exist but if it does not the result depends upon the value of the S argument:
- Let envRec be the object environment record for which the method was invoked.
- Let bindings be the binding object for envRec.
- Let value be the result of calling the [[HasProperty]] internal method of bindings, passing N as the property name.
- If value is false, then a. If S is false, return the value undefined, otherwise throw a ReferenceError exception.
- Return the result of calling the [[Get]] internal method of bindings, passing N for the argument.
We believe that the 4th step is unreachable. In other words, whenever GetBindingValue(N, S) is called, the result of calling the [HasProperty] is always true and here's why:
Yes, that reasoning looks correct.
10.2.1.1.4 may have a similar problem but we haven't checked it yet.
The only immutable bindings present in ES5 are directly initialized before user code can be executed, so yes, step 3 in 10.2.1.1.4 is never reachable in ES5.
We checked with the recent ES6 draft but it seems to have the same issue.
In ES6 it's actually possible to reach that step (8.1.1.2.6 GetBindingValue, step 5), albeit it's a somewhat tricky and involves doing unusual things with proxy objects:
with(new Proxy({}, {
has: function(t, name) {
print("has: " +name);
return !this.called && (this.called = true);
}})) {
(function(){ "use strict"; ref })();
}
That program will give the following output:
has: ref has: ref uncaught exception: ReferenceError: cannot resolve reference: "ref"
Proxy objects allow you to define your own [[HasProperty]]
implementation (the "has" method in the example above). In this case
[[HasProperty]] will return true
on the first call in order to report
a binding is present in HasBinding, but then will return false
when
the binding's presence is checked the second time in GetBindingValue.
On Aug 29, 2014, at 4:07 AM, André Bargull wrote:
...
We checked with the recent ES6 draft but it seems to have the same issue.
In ES6 it's actually possible to reach that step (8.1.1.2.6 GetBindingValue, step 5), albeit it's a somewhat tricky and involves doing unusual things with proxy objects:
,,, Proxy objects allow you to define your own [[HasProperty]] implementation (the "has" method in the example above). In this case [[HasProperty]] will return
true
on the first call in order to report a binding is present in HasBinding, but then will returnfalse
when the binding's presence is checked the second time in GetBindingValue.
And in ES5, host object have similar capabilities. I believe we put this checks in specifically to make sure everything was well defined in the presence of such host objects.
Thank you all for your answers! Your answers were really helpful.
Best,
Sukyoung
Hello,
We found one "dead part" in ES5 and we're wondering whether we're missing something here. The question is about the 4th step in Section 10.2.1.2.4 GetBindingValue(N, S):
10.2.1.2.4 GetBindingValue(N,S) The concrete Environment Record method GetBindingValue for object environment records returns the value of its associated binding object's property whose name is the String value of the argument identifier N. The property should already exist but if it does not the result depends upon the value of the S argument:
We believe that the 4th step is unreachable. In other words, whenever GetBindingValue(N, S) is called, the result of calling the [HasProperty] is always true and here's why:
Let's assume that we're calling GetBindingValue(N, S) where [HasProperty] is false.
Thus, it does not get to the 5th step to call GetBindingValue.
10.2.1.1.4 may have a similar problem but we haven't checked it yet. We checked with the recent ES6 draft but it seems to have the same issue.
Best,
Sukyoung