Re: Calling a field in the same table

[Drake Wilson <drake@...>]

Quoth Luciano de Souza <luchyanus@predialnet.com.br>, on 2010-04-25 08:50:14 -0300:
> You are undoubtedly right. The terms I used weren't precisely and be
> sure I am worried about it. I am brazilian and I don't speak english
> freely. Sometimes, when I write in english, despite being a very
> nice language, I fell myself chained by words. Talking or writing, I
> didn't get the same freedom of expression. It's unbelievable because
> what I did is not exactly an english mistake, but mainly, a concept
> mistake.

I was kind of wondering.  It's hard for me to tell sometimes which
distortions are from language differences and which are from actual
misconceptions, though the idea that the computer will not always
correct for such things is still mostly valid in this field.  I hope I
didn't accidentally offend.

Incidentally, you can view the bytecode generated from a source file
with luac -l -p if you want to see more clearly what happens at that
level, which can be helpful for understanding.  Here's the result for
your first piece of code:

  -- doesn't work
  database =
  {
    filename = 'test.db',
    connection = sqlite3.open(database.filename)
  }

translates to

main <stdin:0,0> (10 instructions, 40 bytes at 0xa3d230)
0+ params, 3 slots, 0 upvalues, 0 locals, 6 constants, 0 functions
        1       [1]     NEWTABLE        0 0 2
        2       [3]     SETTABLE        0 -2 -3 ; "filename" "test.db"
        3       [4]     GETGLOBAL       1 -5    ; sqlite3
        4       [4]     GETTABLE        1 1 -6  ; "open"
        5       [4]     GETGLOBAL       2 -1    ; database
        6       [4]     GETTABLE        2 2 -2  ; "filename"
        7       [4]     CALL            1 2 2
        8       [4]     SETTABLE        0 -4 1  ; "connection" -
        9       [5]     SETGLOBAL       0 -1    ; database
        10      [5]     RETURN          0 1

So you can see that in the current canonical Lua implementation, the
table is first created with no values in it.  Then the "filename"
entry is stored.  Then sqlite3.open is retrieved and called, but the
retrieval of database.filename is through the "database" global, which
has not been set yet, so that fails.  The "connection" entry is stored
into the table, and only after that is the reference to the entire
table assigned to the "database" global.

(And in case you're wondering whether there's a way to reference the
table while it's being constructed, there isn't.  This wouldn't make
very much sense because the order in which the fields are computed or
stored is not guaranteed, so you wouldn't be able to rely on any field
being set while computing another.  That's the main semantic reason
you set the fields one at a time if you need that sort of dependency;
then the order is guaranteed.  It might be even better to use locals
for the intermediary values and only construct the table at the end,
but that's somewhat separate.)

   ---> Drake Wilson