lua-users home
lua-l archive

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


On Mon, Sep 05, 2005 at 02:00:05PM +0800, Michael Richter wrote:
> > 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 same could be said of the lack of built-in OOP support. It's the
Lua way: the built-in libraries give you the basics, and its up to you
to write or steal the additional library code that corresponds to your
usage.

The was an attempt a while back to start a standard library project
which defined a lot of the functional primitives, extra string
operations, etc., and in which a table.isempty function would have
fitted perfectly (I don't think it was in there, though there was a
table.size). No-one had much time to spend on it unfortunately. See
http://lua-users.org/wiki/StandardLibraries.

> My favourite one was how it was faster to clear the 
> accumulator using XOR than it was to load it with 0.

That's true of most processors, as a consequence of the instruction
size, e.g. on i386 (IIRC) XOR EAX,EAX is 2 bytes, but MOV EAX,0 is 6,
because of the need to store the 0 value.

> What is the "correct" answer to this anyway? What is the "Best Known 
> Practices" way of testing for table emptiness in Lua?

In general, next.

-- Jamie Webb