|
Am 2018-03-15 09:23, schrieb Tim Hill:
While I admire the cunning use of undef and the way it is backward compatible, I can see lots of old code breaking as tables fill up with nil values and consume memory (and this is nasty as such breaks will only happen when the code is stressed in low memory situations). It’s also a shame to break the symmetry and clean design of “nil means delete”.
I see the same problems coming. Also, now that there is undef, people will want to store it (in tables, variables, ...), we've already seen examples of this. Wouldn't it be prudent to make this behaviour (storing nils in tables) optional and control it per table using the mode field? Maybe even separately for array and hash part. Then, get rid of undef, which is already confusing people, and instead use table.remove to get really rid of table entries. table.remove would then obviously have to accept ather key types than integers. This could be complemented with a function to remove all entries of a table with integer keys larger than some value.
I think this would be a lot easier to explain, like, "if you want to store nils in tables, set the tables' __mode metafield to include 'y', and bob's your uncle". Also, it would be backwards compatible.
Regards, Gunnar