3 ms·
From what I've read, Lua has apparently done a poor job at maintaining backwards compatibility and Mike Pall is unwilling to support those kinds of changes. I
by TheAceOfHearts 10y ago
From what I've read, Lua has apparently done a poor job at maintaining backwards compatibility and Mike Pall is unwilling to support those kinds of changes.
I don't have enough context to know if breaking backwards compatibility is justified or not. I generally think it's a poor decision that's hostile to developers to break backwards compatibility in a programming language without providing a clear migration path. Issues between 5.1, 5.2, and 5.3 definitely seem to have splintered the community.
http://www.freelists.org/post/luajit/Port-bitop-to-53,1 http://www.freelists.org/post/luajit/Port-bitop-to-53,1
- wwwigham 10y agoI feel that the language itself has remained remarkably compatible through releases. The difficult change, I believe, has been the changes to the API for native extensions (if I'm remembering my history right).
- catwell 10y agoThe backward compatibility issue Mike is ranting about in this post is not in the language, it is in the source code of Lua itself (actually a define in its configuration header file). There was a very good reason for this change, which is that Lua introduced an integer type instead of using floating point numbers for everything. This means that LUA_NUMBER_DOUBLE and LUA_NUMBER_FLOAT do not really make sense anymore (when you check those you may want to check the type of the integer numbers or the type of the floating-point numbers). In any case, porting luabitop doesn't really matter that much: if LuaJIT supported Lua 5.3 people would use the native 64 bit bitwise operators it introduced instead.