Re: no more lua tag methods?

[RLake@...]

> But if you change the gettable/settable for all tables, you can break
> the security of lots of C code. (For instance, you can intercept accesses
> to the registry table.) So, what to do?

Get rid of the registry table and let user-objects participate fully in
garbage collection? Surely that's not so difficult a proposition (and it
would be so cool.)

I really don't think it makes an enormous change. A user-object simply
registers its interest by providing the API with the address of an
object-marking routine; this routine receives two parameters, the lua_State
and the object address, and uses this information to trace its contained
objects, calling some defined API (lua_mark, perhaps) with the lua_State
and the address of the contained object. Or, to be more general, it
receives three arguments, one of which is the function to call with each
contained object. A slightly more general interface would allow objects to
include weak references.

I actually just ran into the "you can't change gettable/settable for
default tag methods" issue trying to work up a little Persistence library,
since that seems to be in a bit of demand (I'll post what I came up with
before the end of the year, I promise).

Here's the question. I want to be able to say:

PersistentEnvironment:register("MyDocument", document)

or some such, and have the environment create a persistent copy of document
(using the name as an index) in some external store... *and* write deltas
to the persistent store when and if they happen. Obviously, I can do that
by insisting that persistent objects need to contain methods to persist
themselves, the approach taken by a number of languages. I find that
tedious; I would like the persistence system to work that out by itself as
much as possible, only requiring my modification if I want to do something
non-standard. (For example having only part of the object persistent; I
would want to divide the object into persistent and non-persistent pieces
and use something like an index TM to autorecreate the non-persistent
piece.)

There is a good argument that there is no automatic behaviour that will
work for any random object, since there is no way of telling what the
object's modification protocol might be. On the other hand, there might be
a large class of interesting objects which share a particular modification
protocol which can be handled automatically; an instance of such a protocol
would be that the object "looks like a dictionary" possibly with a
restricted set of keys. Such an object might well not provide a settable
tag method, and it would be entirely reasonable to say that a registered
persistent object with a tagtype without a settable tag method could be
persisted automatically by trapping all table sets; this behaviour could
easily be overridden by setting the settable method to rawset, for example.
In any event, this is precisely the strategy that one would use for tables
with default tags, so it's a place to start.

Except you can't. So over to you all.... how *should* one solve this
problem (without large amounts of C code, and with additional marks for
elegance)

Rici