 |
lua-l archive |
|
|
||
|
Now that the Book has been out, and Lua should stabilize a bit (;-' how about some thoughts on handling deprecated features.
What I'd want is a way to have a script say "I'm done for Lua 5.0 syntax, please consider that" and so.. This could then be used to handle deprecated vs. "latest and greatest" syntax changes consistently. Also, it would grant the reader of the source to see, which Lua is expected to be running it.
A simple global s.a. LUA_API=5.0 could be used. Note that this info should be in the script itself, not as a command line option or such.
A case worth mentioning is the way Gtk+ API does it. If you define (- D) GTK_DISABLE_DEPRECATED (..well, something like that..) your code won't compile if it uses _any_ deprecated features. Flag s.a. this would have made it easy to prepare for the "for .. table" case in advance. I'd only have it the opposite way: any deprecated features disabled by default.
There are many options, and what I'm calling for is a simple (read: Lua-ish ;) way to get this under control. Slight version changes that require _all_ the execution paths of a program code to be tested before a new Lua can be trusted upon, is hardly the way people would like it.
-ak Mike Pall kirjoitti 30.7.2005 kello 12.59:
Hi, Philippe Lhoste wrote:## The LUA_COMPAT_LSTR=2 is only for compatibility, so it allows nesting only for the simple case [[...]] (without equal signs). ## I think, unless you are doing a project from scratch and disconnected from the rest of the world, that Lua should be compiled with this option, which probably doesn't harm anything.I beg to differ. The new (5.1) behaviour is a lot simpler to understand and to implement. IMHO the Lua authors' decision is right and the old behaviour should go. Just deprecating it in the docs and silently leaving it in, means it never goes away. We've seen that with 'for x in table', which was deprecated in the 5.0 docs. But the complaints started just recently when one of the 5.1-work versions finally dropped it (i.e. a few years later).At least, a Lua lexer/parser should still handle this kind of nesting,to handle legacy code.This is a completely different issue. Tools striving to support multiple Lua versions should probably have a 'compatibility version' setting. Bye, Mike