Re: Can userdate have references to lua objects?

["Peter Hill" <corwin@...>]

RLake:
> Tables only shrink when they are about to grow :)
>
> Most of the time, this is ok, because tables either grow constantly and
> are deleted, or grow and shrink randomly. It will only create a problem in
> the case where a table is grown to a massive size, then most of the
> elements are deleted, and then no new elements are added. If you are doing
> that, you should probably copy the table after deleting the elements.

This doesn't sound very desirable. Ok, it is very unlikely to cause a
problem in practice... but a requirement for a user to poke in a new dummy
value to shrink a table means that their program needs to be *very aware of
the GC and/or table memory allocation mechanisms*. Very Bad. It should all
be transaprent.

> The Lua garbage collector cannot shrink tables, because this would affect
> any iteration using next() which happened to be active; it is not possible
> to know if that is the case, so the garbage collector cannot shrink
> tables.

This all comes back to whether one should be able to scan a weak-linked
table... a touchy issue. Perhaps 'next()' should not be guaranteed to work
reliably on them.

Or perhaps it shouldn't be allowed to work on them at all, and if you want
to scan a weak table then you need to temporarily "un-weak" it. If so, then
'next()' would be restated to not be reliable on both addition AND
subtraction of new keys. This is probably the best solution as far as
transparency goes.

> So the only time a table can be reliably shrunk is when it is about to be
> expanded (and even then only because next () style iteration is documented
> as being unstable if the table is modified by adding a new element.)

Another possiblity is to allow some sort of "next() lock" for tables (stored
in its metatable) that guarantees the correct operation of 'next()'
(preventing size change) while it exists. Note that this then makes no
comment about the GC method; it merely guarantees correct 'next()'
operation.

On the down side a locked table may (unpredicatably) refuse to allow a new
entry because it has run out of space and can't expand. Perhaps the lock
could also specify a 'free space' value, being a guaranteed number of new
values that may be added before unlocking?

*cheers*
Peter Hill