Re: Iterating proxy tables

[Dimitris Papavasiliou <dpapavas@...>]

Hello David,

> Or you could just expose it as a full userdata, with metatable which
> provides access to the members.

Yes it's more or less equivalent.  I can't remember which difference
in the semantics of full userdata vs. table metamethods forced me to
make this choice instead of what you suggest.

> Is it really useful that pairs() functionality be emulated for such a
> struct?  I know that was just an example, but how many elements will it
> have?  I don't think most people would bother implementing pairs() even in
> 5.2 -- e.g.:
>
>> for k,v in pairs(io.stdout) do print(k,v) end
> stdin:1: bad argument #1 to 'pairs' (table expected, got userdata)
>
> After all, the C-struct-as-a-Lua-table paradigm only works to a limited
> extent -- are you going to allow insertion of new keys via __newindex?

I'm not sure if it's practically that important but it seems important
to me from a design aspect.  I'm using Lua as a sort of "interface
language" which in short, and not to bore you with the details, means
that the core exposes its state by means of special tables which you
can create, destroy or manipulate in Lua.  So programming the core
(which does real-time simulation and rendering) feels just like
programming Lua where the tables and the relations you establish
between them has special meaning.  The approach aims to make real-time
simulation application development (games or whatever) simple, so that
anyone can do it given some knowledge of the physics and math
involved.  So simple here means that the programming is simple and
doesn't trouble you with low-level implementation details which have
nothing to do with simulation or rendering.  (This is very different
from "user-friendly" which usually means that you can't do very much
and what you can do you can do in the most cumbersome way imaginable
but at least you don't have to read a manual.)  From that point of
view therefore I'd like these special tables to behave as much as Lua
tables as possible (apart from their "side-effects") so that I don't
have to tell the application developer, "well this is special table so
you can't do this and you can't do that as you might expect" and the
developer won't have to remember all the exceptions.

I do allow assignment of new keys but these are just normal keys
stored in the table and are meant as a convenience so that you can use
the keys which are not special for you own purposes. (And so that the
table behaves as expected of a table.)

> If you must do so, just hard-code the keys (they're already hard-coded into
> the C struct), unless there are really a lot of them, in which case either
> you should use some dynamic data-structure in C other than a struct (which
> will then allow iteration over its keys), or use a code-generator (e.g. cpp)
> to generate both the struct and the list of keys, forcing them to remain in
> sync and effectively providing a limited form of introspection in C.

Yup, these are more or less the approaches I considered.  The dynamic
data-structure in C would imply a lot of unnecessary overhead but the
latter approach is more-or-less (less rather) what I'm doing now which
is to pass the source files containing the __index and __newindex
definitions through a small shell script that extracts the keys and
writes the above mentioned list for you.

Dimitris