|
On 21.03.2018 00:14, Hisham wrote:
On 20 March 2018 at 10:27, Thomas Jericke <tjericke@indel.ch> wrote:
On 19.03.2018 17:16, Hisham wrote:
Every attempt of smoothing out the incompatibility ("strong tables",
undef syntax hack, etc.), while well-intentioned, just adds terrible,
terrible pitfalls to the language (e.g. "Of course you may not pass a
strong table to old libraries").
-- Hisham
I assume you have read my post, as your example is an exact quote from my
mail.
If my assumption is correct. Can you please elaborate what is so terrible,
terrible about it?
Passing a "strong" table to a library that isn't able to cope with it will
get you unpredictable results. That is not nice, but it is not too hard to
avoid.
There are similar problems with tables that have metatables already. You can
actually implement a "strong" table with Lua 5.3 using metatables, therefore
the damage has already been done.
I actually still like to believe, that an opt-in solution (only those who
need it must use it) is possible within the Lua 5 universe without the
language having to take terrible, terrible damage.
First of all, I meant no offense. Lua (like every other language, I
guess) already has major pitfalls (#t being one of them). The pitfall
I was referring to would be the situation where something like {...}
creates a strong table in Lua 5.4+ and a normal table in Lua 5.3 and
below. _Fully opt-in_ strong tables, as you said, are doable in Lua
5.3 today already, and they would not cause terrible, terrible damage
at all, because their use would be explicit (like setting metatables).
As you said, those who need it, use it, and are aware of it.
But I when consider the proposal of strong tables, what I have in mind
is not only "nulls in JSON arrays" but the whole spectrum of problems
that -DLUA_NILINTABLE is aiming to solve, including things like {...}
and {f()} (i.e. the need for select()/table.pack()/table.unpack() in
the language). If constructs like this become strong tables by
default, then it will not fit the Lua 5 universe without bringing
hard-to-track compatibility issues.
(In short, I consider a source of hard-to-track compatibility issues
any proposal that requires a complete dependencies-deep code audit to
ensure that Lua 5.x code will remain working as intended without
introducing memory leaks.)
Each idea has pros and cons. Egor's proposal, keeping Lua 5 table
behavior by default but adding new syntax for tables that behave
differently, is an interesting one. Yes, it means that Lua 6 code
would not parse under Lua 5.x, but it would mean that all existing Lua
5 modules would run on Lua 6 the way their authors intended. Its major
con is that if {...#} means "pack all arguments into this table
including any nils" [1], then we'd get in a weird _javascript_-like
situation where "=== is the correct equality and == is the old one you
shouldn't use anymore but we can't take away", because {...#} would be
the one that "always works" (and {...} would become a pitfall in
itself).
-- Hisham
[1] via either Egor's original proposal of a user-settable length or
combining it with Dirk's proposal to make {...#} the strong-table
constructor
I wasn't offended. Actually I had to smile at the use of the
phrase "terrible, terrible".
I just think it's unfair to criticize the proposal of strong tables
using examples that are actually not part of the original proposal.
That pretty much the definition of a straw man argument.
In your original post you said that *every* attempt to smooth out
incompatibility will lead into pitfalls,
while actually the original proposal doesn't add new pitfalls.
All it does is to standardize something that is already possible
within the current version of Lua.
And hopefully it will highly boost the performance of this pattern,
as implementing strong tables with
metamethods need at least two extra tables IMO.
I pretty much agree on everything else that you said. That's why I
don't like the undef idea.
I neither like the idea, that existing syntax should return strong
tables.
Function redefining may be possible, as it is usually possible to
search for function names like "pack" and "unpack" over a project
easily.
But then again, it might be better to just introduce a
table.strongpack that packs the arguments into a strong table.
I see no problem in adding a new syntax that creates strong tables,
as long as it is possible to use the existing syntax as well.
That would mean, the programmer can decide himself if his code is
backward compatible or not.
--
Thomas
|
