Skip to main content
added 360 characters in body
Source Link
Jörg W Mittag
  • 104k
  • 24
  • 225
  • 324

You have many excellent answers already, but I just want to give a short and clear answer to your answer about how all of this works, and that answer is:

MAGIC!!!

Really, that's it.

The people who implement ECMAScript execution engines have to implement ECMAScript's rules, but not abide by them within their implementation.

The ECMAScript Specification says that A inherits from B but B is an instance of A? No problem! Create A first with a prototype pointer of NULL, create B as an instance of A, then fix up the prototype pointer of A to point to B afterwards. Easy peasy.

You say, but wait, there is no way to change the prototype pointer in ECMAScript! But, here's the thing: this code isn't running on the ECMAScript engine, this code is the ECMAScript engine. It does have access to internals of the objects that ECMAScript code running on the engine doesn't have. In short: it can do whatever it wants.

By the way, if you really want to, you only have to do this once: afterwards, you can for example dump your internal memory and load this dump everytime you start up your ECMAScript engine.

Note that all of this still applies, even if the ECMAScript engine itself were written in ECMAScript (as is actually the case for Mozilla Narcissus, for example). Even then, the ECMAScript code that implements the engine still has full access to the engine it is implementing, although it of course doesn't have access to the engine it is running on.

You have many excellent answers already, but I just want to give a short and clear answer to your answer about how all of this works, and that answer is:

MAGIC!!!

Really, that's it.

The people who implement ECMAScript execution engines have to implement ECMAScript's rules, but not abide by them within their implementation.

The ECMAScript Specification says that A inherits from B but B is an instance of A? No problem! Create A first with a prototype pointer of NULL, create B as an instance of A, then fix up the prototype pointer of A to point to B afterwards. Easy peasy.

You say, but wait, there is no way to change the prototype pointer in ECMAScript! But, here's the thing: this code isn't running on the ECMAScript engine, this code is the ECMAScript engine. It does have access to internals of the objects that ECMAScript code running on the engine doesn't have. In short: it can do whatever it wants.

By the way, if you really want to, you only have to do this once: afterwards, you can for example dump your internal memory and load this dump everytime you start up your ECMAScript engine.

You have many excellent answers already, but I just want to give a short and clear answer to your answer about how all of this works, and that answer is:

MAGIC!!!

Really, that's it.

The people who implement ECMAScript execution engines have to implement ECMAScript's rules, but not abide by them within their implementation.

The ECMAScript Specification says that A inherits from B but B is an instance of A? No problem! Create A first with a prototype pointer of NULL, create B as an instance of A, then fix up the prototype pointer of A to point to B afterwards. Easy peasy.

You say, but wait, there is no way to change the prototype pointer in ECMAScript! But, here's the thing: this code isn't running on the ECMAScript engine, this code is the ECMAScript engine. It does have access to internals of the objects that ECMAScript code running on the engine doesn't have. In short: it can do whatever it wants.

By the way, if you really want to, you only have to do this once: afterwards, you can for example dump your internal memory and load this dump everytime you start up your ECMAScript engine.

Note that all of this still applies, even if the ECMAScript engine itself were written in ECMAScript (as is actually the case for Mozilla Narcissus, for example). Even then, the ECMAScript code that implements the engine still has full access to the engine it is implementing, although it of course doesn't have access to the engine it is running on.

Source Link
Jörg W Mittag
  • 104k
  • 24
  • 225
  • 324

You have many excellent answers already, but I just want to give a short and clear answer to your answer about how all of this works, and that answer is:

MAGIC!!!

Really, that's it.

The people who implement ECMAScript execution engines have to implement ECMAScript's rules, but not abide by them within their implementation.

The ECMAScript Specification says that A inherits from B but B is an instance of A? No problem! Create A first with a prototype pointer of NULL, create B as an instance of A, then fix up the prototype pointer of A to point to B afterwards. Easy peasy.

You say, but wait, there is no way to change the prototype pointer in ECMAScript! But, here's the thing: this code isn't running on the ECMAScript engine, this code is the ECMAScript engine. It does have access to internals of the objects that ECMAScript code running on the engine doesn't have. In short: it can do whatever it wants.

By the way, if you really want to, you only have to do this once: afterwards, you can for example dump your internal memory and load this dump everytime you start up your ECMAScript engine.