Agreeing wholeheartedly, may I pick a nit? Aren't there some
high-level semantics that can be derailed when the programmer has no
option but to work too close to the details? A simple example is
testing for an empty table.
The application of testing for an empty table is very common -- an
empty table conveys an empty set, or a null return value, or an
exhausted collection, etc. But in Lua a higher level thinker has to
resort to lower-level constructs to make this test. I can use the
next() function or, where applicable, I can use the table.getn()
function. But is the next() function "faster", or is getn() "better"?
I don't personally consider that a nit, Bill. I'm reminded, in
fact, of my old Z80 programming days. The Z80 was a cool
processor for its time, but it had... idiosynchrocies. My
favourite one was how it was faster to clear the accumulator using XOR
than it was to load it with 0. (If memory serves. I haven't
touched the Z80 in <mumble> years.) This is the kind of
detail that is maybe alright when you're programming that close to the
bare metal anyway, but in a higher-level language it's preposterous to
see this kind of issue popping up.
What is the "correct" answer to this anyway? What is the "Best Known Practices" way of testing for table emptiness in Lua?
