4 ms·

Javascript (6) has those in the form of Proxies [0]... Coming soon! I think that they cover the set of features you indicate anyways. However, you can already

by euank 12y ago

Javascript (6) has those in the form of Proxies [0]... Coming soon! I think that they cover the set of features you indicate anyways. However, you can already hack them in and there are multiple js projects that let you compile ES6 down to ES5, proxies included. As other commenters noted, python is not "more dynamic" than javascript. You can easily transform python code that does unusual metaprogramming stuff to javascript code that does similar metaprogramming stuff but looks significantly different; basically all languages that support runtime-eval will let you imitate all other metaprogramming features in a somewhat verbose fashion. [0]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Proxy https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

chriswarbo 12y ago
> However, you can already hack them in and there are multiple js projects that let you compile ES6 down to ES5, proxies included. Of course, but will it still be as fast? For example we can trivially turn a Python expression "a + b" into a Javascript expression "a + b" to get a great speed benefit. It may even give correct results in benchmarks, but in general it breaks the semantics and therefore any frameworks which rely on it. FYI in Python "a + b" is equivalent to "a.__add__(b)", and hence the correct Javascript would look more like "a.__add__(b)", but this requires a property lookup and a function call so a lot of the speed gains may be lost (although some benefits may be regained by JITting). Considering that the parent pointed out how small this project's codebase is, it does give legitimate concern about how many rules there are for mapping Python's semantics to Javascript's. For example, the ShedSkin project has been around for years and gets very impressive benchmark results since it compiles Python to C++; however, it tries to map Python classes directly to C++ classes, which breaks the semantics immensely.
- lclarkmichalek 12y ago
  It's even more complicated than a.__add__(b), due to __radd__: https://www.inkling.com/read/learning-python-mark-lutz-4th/chapter-29/right-side-and-in-place https://www.inkling.com/read/learning-python-mark-lutz-4th/c...
- hetman 12y ago
  Which is only the beginning of a full mapping since the method is actually a descriptor. The method lookup has to go through a bunch of rules that mean we get the correct descriptor behaviour in a given context.

by euank 12y ago

chriswarbo 12y ago

> However, you can already hack them in and there are multiple js projects that let you compile ES6 down to ES5, proxies included. Of course, but will it still be as fast? For example we can trivially turn a Python expression "a + b" into a Javascript expression "a + b" to get a great speed benefit. It may even give correct results in benchmarks, but in general it breaks the semantics and therefore any frameworks which rely on it. FYI in Python "a + b" is equivalent to "a.__add__(b)", and hence the correct Javascript would look more like "a.__add__(b)", but this requires a property lookup and a function call so a lot of the speed gains may be lost (although some benefits may be regained by JITting). Considering that the parent pointed out how small this project's codebase is, it does give legitimate concern about how many rules there are for mapping Python's semantics to Javascript's. For example, the ShedSkin project has been around for years and gets very impressive benchmark results since it compiles Python to C++; however, it tries to map Python classes directly to C++ classes, which breaks the semantics immensely.

lclarkmichalek 12y ago
It's even more complicated than a.__add__(b), due to __radd__: https://www.inkling.com/read/learning-python-mark-lutz-4th/chapter-29/right-side-and-in-place https://www.inkling.com/read/learning-python-mark-lutz-4th/c...
hetman 12y ago
Which is only the beginning of a full mapping since the method is actually a descriptor. The method lookup has to go through a bunch of rules that mean we get the correct descriptor behaviour in a given context.