Re: table.copy

["Grisha" <grisha@...>]

I'v found another useful function, IMHO worthy including in the library:

function table.find(t, value)
    for k,v in t do
        if v == value then return k end
    end
end

With respect,
Grisha

----- Original Message -----
From: "Tom Spilman" <tom@sickheadgames.com>
To: "Lua list" <lua@bazar2.conectiva.com.br>
Sent: Thursday, June 26, 2003 8:47 PM
Subject: Re: table.copy


> >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
>