lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

> This new keyword is useless if you see only the final program or module.
> But, if you consider the coding work, it's like Unit Test :
> when you don't use UT, you think that they are expensive and useless,
> but when you use UT, you become addict.
> Because you could refactor your code with confidence.

I am also doing quite a few programming tasks in Java and there, I am
using the final keyword in appropriate cases and I do appreciate its
existence, merely because it simplifies analyzing code that is being
executed in different threads.
But exactly because from these experiences, I don't see the benefit in
Lua code - since my coding style in Lua varies a lot from coding
styles I developed in C or in Java. As said, I can't recall any kind
of debugging session that was complicated because of someone having
changed a variable's value at some point - most of my painful
debugging sessions can be contributed to spaghetti code in combination
with programming patterns that are applied just everywhere (no matter
if it makes sense or not), in combination with copy paste code that
has been partially repaired at some point, in combination with abuse
of keywords (e.g. GSON [1] marks everything anywhere as final, making
it impossible to extend gson classes, making certain things
extraordinarily painful).
Adding keywords isn't going to help making programmers developing a
common sense (in my opinion). I have seen bad code in every language
so far. I doubt that programming languages can prevent it from
happening. I even go so far to believe that having more keywords (thus
making the language more complex) is making things worse. But figuring
that out is for me a work in progress experience and I might change my
mind on that any time.

> There are different points of view :
> - this keyword is not a real new feature, because if you substitute
> all 'final' by 'local' in a program, its behavior is the same.
> - another point of view is : 'final' introduces a support for
> pure functional programming.

It is a new feature because it modifies the parser and adds one new
keyword to Lua. It also requires the parser to check for certain
conditions (onetime assignment) that are currently not checked.
About functional programming: Functional programming is about avoiding
states and having immutable data [2]. If you allow

> final t = {}
> t.a = 1         --> ok

you effectively don't gain much since you don't eliminate the
sideeffect of function calls.
I would see a benefit in conjunction with final functions, where the
keyword "final" would put up the requirement "Function without a
sideeffect", e.g.

final function a (y) return y*2 end
final function b (x)
  y = x; -- <-- compile time error, not a function without sideeffect
due to global variable assignment
  return val + x

Then I would say that it really supports functional programming - but
I would also prefer being able to make such function visible outside
of files. Still: That would put some load on the compiler - and Lua's
first goal is to be small and simple.
So I would rather appreciate a static code analysis tool that could be
run it during development time than a patch that modifies the core.
While I don't see the sense in having a "final" keyword inside Lua, I
believe that a static analysis tool for Lua (that can figure out if a
function is a pure function[3]) code would be a worthy contribution.
Even without a new keyword, such static code analysis could already
being done effectively because it is possible to figure out which
local variables are not changed anywhere and in combination with that,
figuring out which functions are pure.