 |
lua-l archive |
|
|
||
|
On 27.11.2010 1:48, Nick Gammon wrote:
The module that expected to be talking to Lua 5.1 but actually got Lua 5.2 would fail on things like setfenv not existing any more.setfenv and getfenv implementations for 5.2 differ from those of 5.1 only when a function doesn't use the _ENV at all. But I agree, there's no way to have complete compatibility, also C functions don't have environments in 5.2. So, better override the 5.1 with something like an empty dll, so that an error would be raised when a module tries to load it. Or here's a more clean, but harder solution - inspect imports of a module before importing it to ensure it doesn't depend on 5.1 dll and give a pretty error message if it does. This still won't filter out dynamic linking modules though.
Plus, the internal structure of the Lua state has almost certainly changed.That's why it's called internal :) Modules shouldn't access it directly, because it may be affected by fields aligning settings.
Well the DLLs like luasocket don't currently have their own version number in them so why introduce that now? My suggestion was to have the version of Lua required (the major version, like 5.1, 5.2, 5.3 etc).Adding the version number into module name is a bad idea, but it would be good to add an exported function that would return the Lua version that the module was compiled against. More specifically, this function can be implemented in Lua source and the user would simply export it when writing a module.The thing is, minor changes to (say) luasocket, luacom etc. are probably fixing bugs or introducing minor functionality. Like, the difference between Lua 5.1.3 and Lua 5.1.4. So you don't care about that too much. However because of the internal changes to Lua, and the fact that Lua states are shared between modules, means Lua simply *won't run* unless you get the correct DLL linked in dynamically at runtime.
-- Best regards, Sergey Rozhenko mailto:sergroj@mail.ru