3 ms·
Python did have some scheme to do something like this. If you were using gevent, you needed to call gevent.monkey_patch() to override all the network calls that
by likpok 8y ago
Python did have some scheme to do something like this. If you were using gevent, you needed to call gevent.monkey_patch() to override all the network calls that you were making under the hood, so that they would happen on the event loop.
Yes, gevent did have a reference to the classes it was patching, but it still made pretty deep changes to a program.
It was janky and has been replaced several times by other async frameworks. It doesn't go as far as javascript to be sure, but it is sort of what you're suggesting.
- rsj_hn 8y agoYeah, the issue isn't monkey patching per se, but lack of isolation. Javascript just doesn't support the concept of a "module" that cannot interfere with globals via side effects or is somehow restricted to interacting with the rest of the system via a clearly defined API that can be checked without reading all the code in the module. That, combined with the fact that people load thousands of modules just to do simple short programs, makes it very hard to reason about javascript code efficiently. You can try to hide global references from a javascript module, for example by using "with", but you will always have access to things like constructor() which will give you the raw window, so you can't hide a reference to Window even if you shadow Window via "with". Even ignoring that, you still can overwrite builtins from anywhere in the code, thus effectively changing the shared runtime. There is no notion of scoped builtins -- e.g. overwrite builtins all you want, but just in your own scope. That lack of isolation is the problem, not monkey patching your own objects.