[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Best Practices for Lua -> "Lua+"?
- From: "Alexander Gladysh" <agladysh@...>
- Date: Sat, 22 Mar 2008 03:28:10 +0300
My humble opinions on your list:
> * Extending the language syntax for non-programmers (who may be in love with Python's whitespace behavior)
Never. Evil. Non-programmers are not qualified (by definition) to
affect decisions with such heavy consequences.
> * Seperating LuaNumber into ints/floats for range/performance reasons
Never. Not on embedded platform.
> * Extending the language syntax for C/C++ programmers (who may be very deeply attached to +=/++/!=)
Never. Evil. Lua is NOT C/C++. The less things would remind of C/C++
the better code would be written.
> * Adding automatic support for index-based "string identifiers" (used to localize strings, refer to specific animations, etc)
Hmm. I remember a recent post on this subject... Can't remember details though.
> * Adding compile-time expansion of known types (so rather than a table search for a known interface function you'd inject a constant offset into a function array)
> * Adding compile-time replacement of enumerations/flags known in the C/C++ codebase
Doubtful. Only as a last resort to increase performance. Caching in
local variables / upvalues is benefical.
> * Adding a specific allocation/management pattern for single-frame temporaries (like intermediate results in vector math calculations)
Thought about it, never had enough time. Still have to try to switch
to some non-default allocator for whole Lua. :-)
So, the bottom line. I'm a conservative PC developer (with respect to
changing the core language at least), and neither my 50KLOC+ of Lua
code for current project (yep, it grows) nor any of my previous ones
have not (yet) reached the point where I would have to optimize it
However, I "adjusted" Lua in two ways:
1. Compiled everything as C++ to simplify writing bindings. (My
project is in C++.) Not a core change, since it is supported by
luaconf.h. However next time I would probably not do that -- I have
enough problems with switching to LuaJIT now (looks like they're on my
side though, still have to investigate that).
2. Added run-time global protection a-la etc/strict.lua, but enforcing
explicit declaration of each global. Not a core change, because done
by the means of the language. Still, I miss an offline validator
(never had time to write one for my specific case -- yes the lack of
time is my problem). But I believe this is not a feature to be built
in the core, but rather a feature for some lint tool.