 |
lua-l archive |
|
|
||
|
On 05/07/2011 6.46, Josh Simmons wrote: [...]
That seems like over-designing a simple problem. Removing the functions properly, and providing a compat / warning library that re-defines the missing pieces seems much cleaner and more useful to me.
Yes.Moreover throwing an error this way doesn't really help in error management during the porting phase. In fact if the programmer is aware of the changes, he will probably search for any occurrence of a missing function and fix the call site anyway. If the application is large, he may also devise some sort of automatic checking (like defining a global setfenv which throws an error).
If he is not aware, then the program is broken and will eventually fail. The check only allows the programmer to diagnose the cause of the failure in a quicker way when the broken code is executed, but doesn't help in discovering the error earlier. But any programmer upgrading from 5.1 to 5.2 *should* know what he is doing (asking him to read and understand an annotated changelog shouldn't be too much).
The only "innocent victims" of the porting could be non-programmers scripters who may be unaware of the change because it is made behind their back (for example, WoW, I guess). But in this case it should be the people forcing the porting that should create the necessary infrastructure to catch the errors and warn the downstream scripters.
To summarize, IMHO these check unnecessarily litter the core, and still aren't useful for every use case.
Maybe a better solution could be to ship a "checking module" (i.e. "compat52-check.lua") with Lua and tell the programmer to "require" it to enable some compatibility checks.
For functions that were removed without being deprecated in 5.1 (like setfenv), it may be worth to add pointers to alternative solutions (Even if partial). That will help the transition much more. For example, if I'm unaware of missing setfenv and discover then my code is broken, it doesn't help too much to have an error saying setfenv was removed. It would help much more to know that for most use cases there is an alternative (by Sergei Rhozenko: http://lua-users.org/lists/lua-l/2010-06/msg00313.html).
-- Lorenzo