lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

It is interesting that I was just about to start reading the Weak Tables
section of PiL.  I will now do so with greater enthusiasm!

The downside of making the ID scheme transparent is that I'd probably
need to implement it for the dozen or so objects that are permanent
members of the game (and thus pose no danger of stale references), and
that might be a fair bit of coding.  I want to present a consistent
interface for all these objects, so all need to be handled in the same

I think that weak tables will solve the issue of creating an excessive
number of objects very nicely.


Sam Roberts wrote:
On Mon, Jul 6, 2009 at 12:37 PM, Watusimoto<> 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:

"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

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