Re: table.copy

["Tom Spilman" <tom@...>]

>From: "Tobias Käs" <tobias.kaes@gmx.de>
>
> (Better don't consider coroutines, or userdata which represents a network
> connection... thats getting too complex. There might be other objects
which
> cannot be copied at all, and a reference copy might not be desired
either.)

    You seem to insist that to have a function it must solve *every*
situation that could ever occur.  I don't think that should the criteria for
adding functions to the library.  You can always implement your own for more
complex situations, but the library should provide reasonable functionality.

> There is no "general" solution, as your "or" shows, there are (at least)
> two.

    =)

> A recursive table is a table like this:
>
> a = {}
> a.ref = a
>
> Those tables can appear in many different forms, and at least I use them
> quite often, for example in double linked userdata and tables. (metatable
of
> userdata refers to table; table to userdata)

    I do too and run into too many garbage collection problems because of
them.

> In the function you have given, recursion would lead to an infinite loop.
I
> can think of at least three ways to handle this:
> - don't copy recursive tables (thats what I will do since it is the
simplest
> way ;-)
> - keep the reference to the original recursive table (which breaks the
> recursion, but still simple)
> - make a copy which is recursive in the new table (could be complex)

    Recursive tables are a more difficult issue.  Just not supporting
recursive tables is probably the best decision that can be made.  Detecting
the problem would cost enough that it should probably not be bothered with.
Deep copies of recursive tables would just give you a stack overflow error.

> Moreover, you cannot predict if in case of nested tables you want to make
a
> reference or deep copy of the table. Often it will _not_ be enough to make
a
> general decision for the whole copy process.

> And here another example: how to copy metatables?

    Not sure about how often you would be copying complex data structures
like that.  My needs for copy have always been to create a new instance of a
deep structure of simple lua types.  Maybe a new metatable member __copy
which can return a correct copy of the data would solve it.  It would
provide for special cases while still allowing an easy way to copy simple
data.  It may even be good enough to extend table.copy() into a more general
copy().

> Of course you could add a metatable function to every table and userdata,
> which decides how to copy it, but that might lead to a lot of unnecessary
> work (which you wanted to avoid ;-) and blow up lua scripts.

    It just wouldn't be a requirement to have it.  If a __copy is present it
is executed to return an appropriate copy of the table/userdata/etc else the
normal functionality of copy would take place.

> I am still of the opinion that it is the best (and fastest) solution to
make
> a function of your own, since you know which features you need. I doubt
you
> can insert any hard to find bugs, since its easy to test with "simple"
> tables.

    I guess everyone should get back to writing their own library of
standard functions. =)

    Tom