Re: Table constructor question

[Drake Wilson <drake@...>]

Quoth Marc Balmer <marc@msys.ch>, on 2010-12-18 10:51:08 +0100:
> Indeed, when a new table is created on the hdf object, it's metatable is
> set so that I can catch index/newindex.  What I am trying to accomplish
> is to access a C datastructure (the HDF containers) using the Lua table
> syntax (or at least as close as possible) without having to do deep
> copies of the contents of (real) Lua tables.
> 
> And it seems that the assignment in the table constructors don't call
> newindex, so I end up with a (real) Lua table, but can not access the
> values later using my methods.

No, of course they don't.  A Lua table constructor is a Lua table
constructor.  You don't get control over the computation of the entire
expression that just happens to be on the RHS of a table write that
you've overridden with a newindex metamethod; you get the resulting
value.  The code:

  t[x] = { c = d, e = f, g = h }

first creates the table on the RHS, then writes it into t[x].  Period.

So as I said, if you want to support that style, you have to iterate
incoming tables to get any existing values out and treat them as
additional writes.  Yes, you wind up creating an intermediary table
that way, but the example you gave showed a three-element table, which
is not a huge cost unless that's a sensitive inner loop.  (In the
other case, you should add locals to cache the values of hdf.bset and
hdf.bset[n], which would be slightly clearer anyway.)

If we're talking about 100x100 arrays or something, then it's unlikely
that they're going to be specified with a table literal.  You can then
provide an interface to create them (in whatever efficient form you
like) unattached and then just unbox a userdata and transfer a
reference in C when placing them in those slots.

Am I missing something here?

   ---> Drake Wilson