Conflicts between W3C specs and ES5?

[Brendan Eich]

On Nov 18, 2009, at 3:25 PM, David-Sarah Hopwood wrote:

> Brendan Eich wrote:
>> On Nov 17, 2009, at 6:41 PM, Maciej Stachowiak wrote:
>>
>>>>> otherWindow.copyOfEvalFromYetAnotherWindow("...") throws
> [...]
>>>>
>>>> What is the rationale for throwing in this last case, rather than
>>>> using the explicit base object (otherWindow) as |this|?
> [...]
>> The standard ECMA-262 semantics want otherWindow -- "bound method"
>> exceptions prove the rule.
>
> There are bound methods in ES implementations? I'm all ears.

There certainly are. First, I was not referring to any built-in magic.  
Function.prototype.bind and similar such APIs were developed first by  
Ajax libraries and used to force |this| to a preset value, instead of  
using a base object in the callee reference pair (base object,  
property name).

But, of course, host objects in various implementations sport bound  
methods. The original ones I know of came from the Java/JS bridge,  
"LiveConnect", because Java method reflections in JS seemed not  
usefully extractable as first-class functions. Instead, extraction  
binds method to receiver, so application coerces |this|.

(E4X (ECMA-357) has methods that can't be extracted at all, they are  
invoke-only; this is even worse than auto-bound methods!)


> (One thing I've never understood is why ES implementors add features
> or exceptional behaviour that users of the language could only find,
> or even know to look for, by reverse engineering or guesswork. What's
> the point? Doesn't it take more work to add all this stuff?)

No, it takes less work to hack "privileged" C++ than to figure out how  
to host the magic in-language. The proof is in the proliferation of  
bad host object magic.

If JS had time to be bootstrapped a la Smalltalk, with small native- 
method "area" and API surface, then it would be a better world. But  
like Java, JS was and is native-code-heavy in its popular  
implementations, and this means host magic.

/be