Re: A friend's issues with Lua

[Jules Bean <jules@...>]

On Fri, Aug 15, 2003 at 01:00:11PM +0100, Rob Kendrick wrote:
> * The whole argument passing mechanism is incredibly grungy, when they 
> * already have a much nicer mechanism staring them in the face - tables. 
>   This depends on your point of view.  You can use tables for passing
>   paramters if you wish (ie, wibble{parm1, parm2, parm3=value3} etc).

I agree with your friend here, actually ;-) I don't like this 'hidden'
type which is list or tuple...

> * The modularity is very weak (no ability to protect any aspect of
> * anything, everyone has the freedom to place anything in any 'namespace' 
> * [i.e. a.b.c kind of place]). 
>   Simply untrue.  Metatables allow you to protect pretty much anything.

lua4: clever tricks with set/getglobal tags, but it's a mess

lua5: metatables and environments appear to provide a fairly elegant
solution.

> * Very quirky string literals mechanism, with missing features.
>   Very subjective.  I've never really found a missing feature that wasn't
>   easily and nicely covered by some other feature.

I don't understand what he means here....

> * No hex constants.
>   Not an issue.  You can use hex values in your source, although not
>   constant.  Performance isn't the main aim of Lua, so it's no problem.
>   I'm sure you could tweak the parser to accept them anyway.

I thought performance *was* an aim of lua, actually. But you can
always make your sure hex values are only set once, so the
hex-conversion function isn't re-evaluated all the time,

> * The whole syntax looks a little fragile, in terms of giving unexpected
> * results rather than errors, if you get things wrong. 
>   This is a personal source code style.  I don't find it fragile at all.
>   The only slight issue is that it leaves the type checking to the
>   function being called.  I personally find this makes everything much
>   more flexible.

There is some fragility inherent in the fact that typos (i.e. mispelt
identifiers) cause, in general, unexpected behaviour at runtime
instead of an error.  You can patch up this problem to some extent
with set/getglobal or metatables to restrict creation of new global
variables.

> * If there's a way to remove elements from tables, I missed it.
>   You did.  table.remove()

That's for arrays.  For general tables, the thing he missed is
probably table.key = nil.

Jules