[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: RE: GC Metamethod and Tables
- From: virgil@... (Virgil Smith)
- Date: Tue, 12 Aug 2003 17:19:38 -0500
>> A. All the other metamethods work for tables as well as userdatas, why
>> goofy exception?
>This is my explanation, and I don't speak for the authors, but here's what
>always assumed: Userdata finalizers are there because the resources used
>have completely arbitrary finalization semantics (for instance, the
>be a struct holding a pointer to dynamically allocated memory). The
>semantics for tables, in comparison, are simple: References to all keys and
>values, and to the table's metatable, are removed. So it isn't so much
>to not have a table __gc metamethod, as it is for userdatas to need one.
Going out of your way to remove functionality, even if <you> happen to think
it isn't needed is "goofy" in my book. One should have a good reason to
break consistency, not just a reason that breaking it might be OK. So, I'm
curious, what was that reason?
>In your case, the simplest way I can see would be for the userdata stored
>table to contain whatever information is needed for finalization.
Because that information may need to be accessible to Lua code.
Yes I CAN <<mostly>> make a userdata look like a table, but why should the
users have to reimplement base language features (tables)?
If one really follows this reasoning then my base library table should have
been a userdata rather than a table, and then I should have supported the
indexing metamethods so that the user's of the library could call its
functions, change its settings, access its help table/strings, etc.
Again I ask, why should a user have to reimplement a <very> base language