[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: [ANN] Lua 5.2.0 (beta-rc5) now available
- From: Lorenzo Donati <lorenzodonatibz@...>
- Date: Tue, 05 Jul 2011 09:21:58 +0200
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.
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: