Re: Let deprecate to-be-close variables as harmful concept

[Francisco Olarte <folarte@...>]

On Tue, 3 Oct 2023 at 09:28, kovserg33@gmail.com <kovserg33@gmail.com> wrote:
> To be close variable ( https://www.lua.org/manual/5.4/manual.html#3.3.8 ) in form it implemented is harmful by nature.

Do not use them, problem solved.

> They introduces unnecessary complexity. This implementation creates more problems than they solve.  It will lead to bugs on all levels. Even more this problems will be hard to find and debug.
...
> More over every thing to manage resource lua has before version 5.4. One possible solution for resource management is
> https://raw.githubusercontent.com/kov-serg/lua-aux/master/proto-seq_fn.lua
... Then use that if you like it more.

> Have any reasonable objections?
Any half-competent programmer can shoot her own foot. I mean, your
code, properly commented, would be a nice addition to a Lua book, like
"things not to do in Lua", or "the annotated lua reference manual: to
be closed variables: things to avoid". I'm not going to analyze your
pointed code, it seems correct but too complex for a quick message,
but I'm sure a similar misuse can be written.

They solve a similar problem to try-with-resources in other languages,
they are easy to use properly. I have lots of "classes" with an
idempotent close() method, called by __close and __gc appropiately,
and have zero problems using them. I had it before <close>, changing
to use it has been simple, simplified some code and reduced some
memory consumption.

In other places, I did not use it and still do not use it, but is a
simple tool which solves a lot of problems when used appropiately.

By the way, things like a=0 are also use to misuse. Zap some of them,
or add some extra ones and code misbehaves too. Not the case in your
sample, it seems to work exactly as designed.

Francisco Olarte.