Of course, most of LuaJIT is applicable to JS as well. Mike Pall simply implemented it better than whole teams at Google and Mozilla. Yeah. Dude's pretty smart.
Of course, most of LuaJIT is applicable to JS as well. Mike Pall simply implemented it better than whole teams at Google and Mozilla. Yeah. Dude's pretty smart.
I don't know, the ES6 inclusions aren't generally increasing the data model complexity.
As far as I can tell you can't something like:
Array.prototype[0] = 5;
and make [] the same as [5].
There's a lot of edge cases in javascript that make its optimization much more complicated than lua's.
http://www.lua.org/pil/13.4.1.html
Importantly, `tbl[key]` only consults `__index` if `key` isn't actually a key in `tbl`, so keys in derived objects override keys up the prototype chain.
http://stackoverflow.com/questions/7015693/how-to-set-the-pr...
I ran into this a little while back while trying to port some Lua code to Javascript. It was very annoying.
ES2015 standardised the read/write __proto__ attribute (which most browsers had implemented for a long time), and added a #setPrototypeOf call. The first answer of your link notes exactly that.
> ...the answer below is no longer accurate. _proto_ is being added to ecmascript6 as "normative optional" which means it isn't required to be implemented...
It can't always be polyfilled, either, which makes the feature effectively useless. I'm not even sure why they added it as such a half-hearted feature to ES6; I suspect politics (Brendon Eich appears to have been dead set against having mutable protos for years).
Fuck's sake mate, Object.setPrototypeOf is not optional (and __proto__ is only optional for non-browser environments).
> It can't always be polyfilled, either, which makes the feature effectively useless.
That's breathtaking dishonesty.
local t = setmetatable({}, {
__index = pcall, __newindex = rawset,
__call = function(t, i) t[i] = 42 end,
})
for i=1,100 do assert(t[i] == true and rawget(t, i) == 42) end
[LuaJIT has no problems with this code and turns it into 8 machine code instructions for the actual loop.]Anyway ...
This permanent excuse of JavaScript proponents that it has more complex semantics, which somehow prevents it from being made fast, is getting old. There are no insurmountable obstacles to make JavaScript fast -- it just takes more effort!
And they dug this hole themselves, by not cleaning up the language and allowing new complicated features into the language. Well ...
Array.prototype[0] = 5;
and make [] the same as [5].
Huh? I don't know what you mean by this.In lua you can easily replicate javascript's prototype inheritance.
The former allows straight forward optimization of the simple case, simply accepting the performance hit of the stuff built on top (which still might benefit from some of those optimizations), while the latter forces the optimizer to invest a large effort into distinguishing between the simple case and the exceptional, and then there still needs to be an always-on fallback path from simple to exotic.