1. I notice in the __add & __unm examples within the book on pages 58,59, the original tables are connected to the mt metatable, but then, the temporary table result within these functions is also connected to the mt metatable.

    eg: local result = setmetatable({}, mt)

    The book doesnt really explain why. except to make known it is doing so.

    what difference would it make if it wasnt?

    eg: local result = {}

    I tried it and it appears to wield the same result.

    It seems to me, this is optional to prepare the new merged table for future addition operations.

    If this is the case then I guess I just discovered that metatable associations are kept intact when duplicating a table.

    love the book btw, cant wait for the 2nd edition. :)

  2. I notice in the __add & __unm examples within the book on pages 58,59, the original tables are connected to the mt metatable, but then, the temporary table result within these functions is also connected to the mt metatable.

    eg: local result = setmetatable({}, mt)

    The book doesnt really explain why. except to make known it is doing so.

    what difference would it make if it wasnt?

    eg: local result = {}

    I tried it and it appears to wield the same result.

    It seems to me, this is optional to prepare the new merged table for future addition operations.

    If this is the case then I guess I just discovered that metatable associations are kept intact when duplicating a table.

    love the book btw, cant wait for the 2nd edition. :)

  3. Because if you don't you can't use the result in a chained arithmetic expression.  Take the following example (using the same code setup, except changing the result line you mention:

    > foo = tbl1 + tbl2

    > bar = tbl1 + tbl3

    > baz = foo + bar

    stdin:1: attempt to perform arithmetic on global 'foo' (a table value)

    stack traceback:

    stdin:1: in main chunk

    [C]: ?

    Since neither foo nor bar has the metatable set Lua doesn't know how to perform addition on them.

    It seems to me, this is optional to prepare the new merged table for future addition operations.

    If this is the case then I guess I just discovered that metatable associations are kept intact when duplicating a table.

    I wouldn't realy say this is optional, becuase if you are doing something with basic arithmetic on tables, it makes sense to ensure that your results are also usable in that context.  However you are incorrect, there are no metatable associations in the new table, and there isn't a way to duplicate a table, really.

    In the code we create a new table and then copy some elements into it.  In the code in the book, we also ensure the metatable on the new table is set so arithmetic works properly.  This all has to be done manually, there's nothing magic happening behind the scenes.

  4. I wouldn't realy say this is optional, becuase if you are doing something with basic arithmetic on tables, it makes sense to ensure that your results are also usable in that context.

    I meant "optional" in a sense that the function would still work without the reconnection of the metatable, even though it would'nt be awfully wise. but if there were a hypothetical case where I knew for a fact that the new merged table would never need to be merged with another, it would be ok to skip the reattachment?

    However you are incorrect, there are no metatable associations in the new table, and there isn't a way to duplicate a table, really.

    I thought that if you create a table, then assign that table to a new variable, it is a duplication. But after reading what you said, I played around & realised that a table isnt actually being duplicated when it is returned from a function or assigned to a new variable, since it retains the same ID, just gets a new name, like a link, a shortcut of sorts. so when a metatable is attached to a regular table, it is attached to the table ID, not the variable name?

    Thank you James, I am truly honored to recieve guidance from someone as skilled as you.

  5. XSSFilter could not parse (X)HTML:
    
    
    
    <blockquote>
    <blockquote>
    <p>I wouldn't realy say this is optional, becuase if you are doing something with basic arithmetic on tables, it makes sense to ensure that your results are also usable in that context.</p>
    </blockquote>
    
    
    <p>I meant "optional" in a sense that the function would still work without the reconnection of the metatable, even though it would'nt be awfully wise. but if there were a hypothetical case where I knew for a fact that the new merged table would never need to be merged with another, it would be ok to skip the reattachment?</p>
    
    <p></blockquote></p>
    
    <p>Yes, you could leave it out in that case.</p>
    
    
    <blockquote>
    <blockquote>
    <p>However you are incorrect, there are no metatable associations in the new table, and there isn't a way to duplicate a table, really.</p>
    </blockquote>
    
    
    <p>I thought that if you create a table, then assign that table to a new variable, it is a duplication. But after reading what you said, I played around & realised that a table isnt actually being duplicated when it is returned from a function or assigned to a new variable, since it retains the same ID, just gets a new name, like a link, a shortcut of sorts. so when a metatable is attached to a regular table, it is attached to the table ID, not the variable name?</p>
    
    <p></blockquote></p>
    
    <p>Remember that there is a difference between values and variables.  A table is a value (these look like table: 0x123fa0 when you print them) and a variable is a just a binding between a value and a name.  When you do the following:</p>
    
    
    <pre>foo = {}<br />bar = foo</pre>
    <p>The first line creates a new table and binds it to the name foo, while the second line creates a new binding from the same table to the name bar.  The value isn't duplicated in any way, and you can see this by making changes to <code>foo</code>, it will be reflected in <code>bar</code>.</p>