Conflicts between W3C specs and ES5?
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.
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.
(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?)
In the case of the original topic (eval), in JavaScriptCore it is only
"bound" enough to reject being called with the wrong "this" object; it
does not do anything else with its stored original global object. We
did this solely to match the ES4 "reformed eval" proposal at the time,
as I mentioned on the public-script-coord list.
, Maciej
On Wed, Nov 18, 2009 at 4:16 PM, Brendan Eich <brendan at mozilla.com> wrote:
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.
IE's famous appendChild "performance trick":
var bodyAppendChild = document.body.appendChild; bodyAppendChild(document.createTextNode("hello"));
blogs.msdn.com/ie/archive/2006/08/28/728654.aspx
The results in an error in other browsers; not IE (to be expected).
DOes that fit the definition of "bound method"?
Maciej Stachowiak wrote:
On Dec 3, 2009, at 4:06 AM, Jorge Chamorro wrote:
Object.prototype.k= 27; console.log(k); -> 27
For it's the last place where a reference would ever be looked up... or not ? (now me ducks and runs :-)
No, the prototype chain is a separate concept from the scope chain. Entries in the scope chain are conceptually objects each of which has its own prototype chain.
<pedantry>
That's true in ES3. In ES5, entries in the scope chain are environment records, which can be either Object Environment Records that each have a prototype chain, or Declarative Environment Records. </pedantry>
Brendan Eich wrote:
There are bound methods in ES implementations? I'm all ears.
(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?)
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. (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?) -- David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 292 bytes Desc: OpenPGP digital signature URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20091118/202a4e29/attachment.bin>