On Mon, Jul 6, 2009 at 12:37 PM, Watusimoto<watusimoto@bitfighter.org> wrote:
Yes, I thought about that... the downside is that it would require a
little more effort on the Lua side (i.e when do you use the object
itself, vs lookup the ID), and I feel it is important to streamline the
Lua coding as much as possible, as it will be exposed to (advanced)
users, not just devs. More streamlined == less documentation == less
support == happier devs :-)
Absolutely agree.
And even so, I would still need to handle the situation where some
wayward Lua coder stores a reference (rather than its ID), which would
likely bring the whole game down if the script used it after the
underlying object were deleted. I need to make sure that can't happen.
I'm not suggesting that anybody coding in lua even know that lookups
are occuring.
If you are interested, I explored some of the alternate strategies here:
http://stackoverflow.com/questions/1047212/detecting-stale-c-references-in-lua
"Now, when the Lua script requests a LuaShip object, I create a new
one and hand it off to Lua, and let Lua delete it when it's done with
it."
"The only drawback is that I'm potentially creating a lot of LuaShip
objects, but it's really not that bad."
I'm saying, when the script requests a LuaShip object, don't create a
new one if one already exists. It's unnecessary. If it already exists,
just return the one that exists.
Lua has a mechanism called weak tables that allow you to keep track of
all LuaShip objects, look them up via the c++ ship pointer, and most
importantly, to prevent the existence of the table to count as a "ref"
for the purposes of garbage collection. Without the "weakness" of the
lookup table, the lookup table itself would prevent LuaShip objects
that are no longer referenced by your user's lua code from ever
getting garbage collected.
Sam
