RE: GC Metamethod and Tables

[virgil@... (Virgil Smith)]

>> A. All the other metamethods work for tables as well as userdatas, why
the
>> goofy exception?
>
>This is my explanation, and I don't speak for the authors, but here's what
I've
>always assumed: Userdata finalizers are there because the resources used
may
>have completely arbitrary finalization semantics (for instance, the
userdata may
>be a struct holding a pointer to dynamically allocated memory). The
finalization
>semantics for tables, in comparison, are simple: References to all keys and
all
>values, and to the table's metatable, are removed. So it isn't so much
"goofy"
>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
in the
>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
feature?