On Tue, Nov 14, 2006 at 12:21:27PM +1100, Mike Kreuzer wrote:
Sure, there are bindings & wrappers, but so far the ones I've looked at
(& I haven't investigated yours) either act with the same carte blanche
with regard to changing their APIs, or they don't update at all.
Not updating seems to be a popular choice, but what possible goal
could be achieved by fragmenting the user base between different
versions of the language?
(A goal--as I see it, at least--is to avoid bloat. You describe a side-
effect. The above is like saying "what possible goal could be achieved
by stubbing your toe?" to someone who wasn't wearing shoes and, as a
side-effect, stubbed his toe.)
OK, I'll up the ante with Santa. Now I'd now like backwards
compatibility for Christmas as well. From version 5.1, any 5.1 script
should run in any future version of Lua. If the language is mature, and
I think it is, then it's time to say so.
The Oxford English Dictionary has a very simple rule for deleting a word
once it's in the dictionary: They don't. I think we should adopt the
same approach with language features. It might concentrate minds a bit
when new features are being considered.
This is the "feature bloat" approach: once a feature is added, it's
stuck in the code, even when it serves no purpose but backwards
compatibility, and even when that compatibility causes code bloat,
design bloat--you have to design around the need for those features,
forever--and maintenance bloat--you have to test these features and
keep them working.
I don't want a Lua where luaL_checkudata has to always return NULL for
backwards compatibility, even though the rest of the check* functions
throw errors. I want a Lua that's consistent today, even if it means
more work to upgrade. I don't want these deprecated functions and
features to stick around in the code and headers and documentation
forever; I want them to go away.
I don't want Lua's evolution stunted by backwards compatibility.
