RE: tables and the gc

["Thomas Wrensch" <twrensch@...>]

>>> RLake@Oxfam.org.uk 05/01/03 10:34 AM >>>
> Ummm... You could just attach the __gc method to the 
> userdata and just use it rather than wrapping it.

I don't think that would work in this case. Remember the original
purpose was to allow a resource to be "deallocated" either manually
using some kind of delete function or automatically if it wasn't done
manually. If the tag was connected to the userdata __gc method it must
either be able to tell that it has been deallocated (by the manual
method) or it might try to deallocate it twice. Might work fine in some
applications, but not in general.

> It is useful to attach  tables to userdata as
> well, but that can be done in at least two ways:

> 1) Use the metatable. This has the disadvantage that 
> you cannot also verify the "type" of the metatable,
> although there are ways around that (like
> locking the metatable).

2) Use a weak-keyed table keyed by the userdata.

Too true. Tables are awfully handy. When possible I prefer using a table
as a wrapper or proxy to a userdata rather than trying to flip it
around. The lack of a __gc meta tag for tables makes this approach more
awkward.

> Your example of lazy serialising of expensive 
> computations is interesting, though. This finally gave
> me a chance to experiment with newproxy, although
> I'm not convinced that it is the best mechanism for
> this.

I first ran across this for use in memoization (this means caching
computed values if you haven't run across the term) and I've put it to
good use a few times. I'm not sure about the newproxy approach, I
haven't had a chance to look at it myself.

  - Tom