Re: Finalizers on tables.

["Adam D. Moss" <adam@...>]

"Adam D. Moss" wrote:
[snip]
> Apart from being kludgy (1-byte dummy userdata and the
> C<->lua trips this implies for its creation, etc) this has one
> rather large fly in the ointment which is the whole stupid
> notion of finalizer-data; the finalizer CANNOT get a
> reference to the original table because its destruction was
> the event that triggered the finalizer in the first place,
> which is why any vital data that the finalizer function needs
> to know about the table it is being invoked for has to be
> duplicated into the finalizer-data table.
[snip]

If anyone's interested, I figured out the last piece of the puzzle
to make this transparent and let the table's finalizer method
get a reference to the table 'from beyond the grave!', getting
rid of the stupid notion of dtor-data.

The solution was to over-write the table's reference with
a 'proxy' table when adding the destructor method, keeping
a reference to the real table behind the scenes and proxying
all read/writes through the proxy table into the real table
using __index/__newindex metamethods.  So after adding the
dtor method the caller's table reference has been substituted
with the proxy without it knowing.

It's still kludgy and (I imagine; haven't timed) there's quite
a speed hit in proxying read/writes for all of the tables you want
dtors for, but it seems to work transparently and thoroughly as
expected.

mytable = SET_DTOR({"wibble", "splarn", 69, "groink"}, my_dtor_func)
mytable.mrarr = "mreee!"

... and when mytable gets gc'd, my_dtor_func(mytable) will
effectively be called.  Hooray.

--Adam
-- 
Adam D. Moss   . ,,^^   adam@gimp.org   http://www.foxbox.org/   co:3