Re: Question on get/setmetatable()
[
Date Prev][
Date Next][
Thread Prev][
Thread Next]
[
Date Index]
[
Thread Index]
- Subject: Re: Question on get/setmetatable()
- From: Lorenzo Donati <lorenzodonatibz@...>
- Date: 2020年5月20日 20:41:30 +0200
On 20/05/2020 16:39, Andrea wrote:
pocomane,
If you introduce a new keyword "const", the following script will not work
anymore in the new lua:
local const = 2
print(const)
Thank you! now I got it!
However, there are always incompatibilities, see the corresponding section
in the reference manuals of Lua 5.x.
So why this incompatibility is deemed not acceptable?
Even if there is the incompatibility, it seems very easy to fix. Just
search the source code for "const" and change it where needed.
And finally, we could check how frequent "const' is in the existing
codebase, so we can estimate how much of it will be broken in case we adopt
"const".
It may turn out that really there is no problem with the old code because
no one was using "const".
This is not so easy as it seems. This just seems easy if you think of
small codebases of non-critical software owned by a single person and
/NOT/ widely deployed or distributed.
Searching and modifying a whole codebase for the use of the word "const"
on large codebases is not so easy to automate. And do you want to
automate it, don't you? You wouldn't want to go manually searching and
replacing with and editor on a gazillion files!
You may think, let's run a regex engine on the whole codebase and change
every occurence of `const` into `const_`.
Well, what if `const_` was already defined? Ok, so you need to build a
system that checks that the new name is not defined anywhere in your
entire codebase and produce an algorithm that changes the substitute
name with something not in use.
Easy? Have you thought of strings? How do you handle the word "const"
appearing in strings? Oh well, just build a parser that identify Lua
strings and turn off substitution inside Lua strings. And comments?
Those are to be skipped too. And "doc" comments? Oh! Another
complication for the parser.
Now we are ok? Aren't we? Wait! Lua is an embeddable language, so we may
have a C application where Lua code is /embedded/ as /C/ strings. So we
must scan C source files for strings containing Lua code, which in turn
may have Lua strings inside them! Ugh!
Ok, we build such a monster code analyzer, which embeds a Lua parser, a
C parser and some clever decision algorithms on when making the change.
Now, what about code generators? Lua is cool also because you can
generate Lua code by splicing strings together and those strings may be
compiled with "load" and become part of your running code. What if some
generator ends up generating a stray "const" where it causes a syntax
error when upgrading? So we must check any part of the codebase which
could generate that thing. And probably this won't be so easy to automate.
And what about DSLs? An application could read lua files that use the
word "const" as a function name with a syntax like this:
const "123456"
const "hello!"
and that file could not even have .lua extension.
Can you see where this is leading? An upgrade nightmare.
And even if you did all the steps right, you might miss some corner
cases that will bite you in the ass two years down the road.
And think also of clients of your application. Imagine a client getting
the upgraded application and suddenly their scripts don't work any longer.
And then you need lots of testing because your automated tool touched
almost any file in your codebase. Would you REALLY trust an
automatically modified source file without extensive testing?
Of course many pitfalls I mentioned could be solved, but this could cost
LOTS of money on big projects. Money that actually brings you almost
nothing, except a slightly cleaner syntax.
Lua is a mature language used standalone and especially embedded in many
applications. Backward compatibility for big codebases meant to be
robust is a big deal.
Like it or not Microsoft has made a fortune by maintaining compatibility
with old versions of Windows (I can still run some nice tools built in
2002, meant to run under Windows98, without a glitch!).
The only thing that I do not like is that this would be a new keyword and I
do not like adding too many keywords to the language. Lua is minimalistic
and I like it as it is.
Anyway I would prefer not to use the angle brackets <const>.
"local const a = 1" or "const a = 1"
is indeed cleaner and would be closer to the overall cleanliness of the
language source code
Despite my long explanation above, I do value cleanliness and the new
syntax doesn't sit too well with me, but I can understand why Lua Team
went for it. And I'm willing to grok it just to have "const" variables.
They are, IMO, very useful to break long expressions and introduce new
variables to make code more readable, without risking of introducing
uninitialized/modifiable variables in the picture.
This could also open up some margin for optimizations in the future.
Moreover I just trust Lua Team's judgement for the future evolution of
Lua not to become a C-syntax nightmare, where ugly patches and stiches
were added to the language for the sake of backward compatibility and
almost never changing the language because you can't break too many old
habits[1] and codebases.
Lua Team has already proven to be able make somewhat drastic choices in
the past just to keep the language lean and clean, so I'm not afraid
about Lua code becoming too akin to line noise. :-)
thank you very much anyway for answering my question
Andrea
Cheers!
-- Lorenzo
[1] I do hate with a passion to remember how many and different
identifiers are reserved in C: mem*, str*, *_t, everything beginning
with _ and a capital, every all caps identifiers beginning with E, and
what else!?!. In a modern language I just want proper namespacing
facilities, not tons of conventions to avoid clashing, especially when
clashing doesn't mean a clean syntax error but nasty undefined behavior!!!