Re: lua hacking wondering

[Dimitris Papavasiliou <jimmyp@...>]

On Friday 25 June 2004 21:05, Virgil Smith wrote:

> -- Maybe in receiving some (very reasonable) criticism that generality is
> generally preferable, I've found a supporter for my stance that tables
> should have gc metamethods. :-)

Maybe. Although the concept of the metatable is very interesting there's 
something that's bugging me with the way it's currently implemented in Lua. 
Let's take it from the top. What makes Lua so cool (IMHO) is the fact that 
it's designers noticed that the concept of an associative array (aka a table) 
is so generic that it is the only complex structure needed in a  generic 
(very) high level language. It has been used to implement structures, 
classes, namespaces, etc. with just some syntactic sugar to make it look 
neater. So, since Lua is an embedable language, being able to hook C code 
into table operations would make it possible to synchronize Lua and C 
objects. So tables can be used to implement (or rather to "expose", to 
provide an interface via Lua for) C objects as well.
So when asking ourselves what metamethods should there be for a table IMHO we 
should not think of what cool features we could implement using metamethods 
but simply what operations can be performed on a table. If we can hook C code 
into everything that can be done on a table then we can implement anything we 
want on top of it. (These operations are of course get,set, all math 
operations, next, collection etc.)
Furthermore what the heck do we need userdata for? Just attach a C buffer to a 
table so that you can conveniently associate C/Lua object pairs and you have 
userdata and tables all in one (they are almost the same anyway). Some people 
will have a problem with this but this may be due to the current way of 
thinking when writing programs. Since the theory behind it seems logical (I 
might be wrong of course) it should work ok in all cases. So in this context 
tables should have a gc metamethods too.
And since the first reply will probably be that "merging" userdata and tables 
will introduce memory overhead when not using the table part I should add 
that if this is indeed a problem (I don't know how big an empty table 
structure is), it can be optimized by e.g. allocating a table only if 
requested and vice-versa. This is way off-topic of course. Maybe we should 
take this on a new thread but I doubt most will find this sufficiently 
important as the current design works too.

> -- BTW: Thanks again to the Lua authors for making such a wonderful tool
> generally available!!!  Engineers and software developers will fixate on
> endless details that they want to "improve", but that does not mean that we
> don't admire the whole (or that we should forget to say so almost as much
> as we go on about the details that we would change).

As I have said before(I think), I haven't been more amazed by the design of a 
language (at least most aspects of it) since I saw that of C. This is no 
small feat. Let's hope we can make it even better.

-- Dimitris