RE: problem with lists and weak references in pure LUA

[Benoit Germain <bgermain@...>]

Mark,

Regarding your weakref suggestion:

I also had a third approach that I did not mention in my original post:

On one hand, I have a double linked list of simple tables that hold their
priority. (list nodes, in other words)
One the other hand, I have the subscriber objects.
Then I have a table that uses the list nodes as keys, and the subscribers as
weak values.
Traversing the list gives me successive keys to retrieve subscribers in that
table. If a subscriber is nil, the node is unlinked and removed from the
table.
This is nothing more that moving the weak reference outside of the node
while keeping the node->subscriber link information, because I can't have at
the same time strong inter-nodes references, and weak node->subscriber
referencing.

Now about the priority sets:

Order within a priority set is not important, and priorities are numbers, so
I can perfectly do weak sets. That was my first approach (but I called them
'equivalence classes' instead), but I still have the priority sorting
problem to fix:

A sorted array of weak sets supposes that I get an array, and not a hash
table, so that traversal with ipairs() gives me all the sets. I would get
them with pairs() but order can't be guaranteed when traversing the hash
part of the table. And ARRRRGH! I just realised that traversing with
ipairs() stops at the first gap!!! Well, I can always prefill my array with
dummy sets, and make sure that no holes get in the way when a new priority
is used...

Anyway. This array/hash repartition is dependant on the strategy that lua
tables use to store pairs with integral keys: depending on their density, I
might end up with a hash table instead of an array. Well, I suppose that if
the message subscribers use priorities 1 and 1000, I don't want an array
with 998 unused slots. But I can definitely live with priorities in the
range 1-20. Unfortunately I am not sure that a table will always store that
range of integral keys in the array part, depending on the order in which
the references are used and their actual 'density' in the used range.

That's why some more information and control on table contents would be
pretty useful at the lua level, at least to be able to raise errors when one
expects indexes to be stored in the array part and they are not.
- give current index range in the array part
- give number of used/unused slots in the array part
- give what maximum index can be used as a key so that it will not go in the
hash part of the table
- one can also dream of an event that would be called when internal
reorganisation occurs (ie index usage is decided to be non optimal, thus
some indexes are moved from the array part to the hash part, or the other
way around)
- one could also dream of a table flag that could enforce the use of the
array part for integral indexes, whatever their density may be (but this
supposes that the user knows what he's doing, and anyway __newindex can be
used to make sure that the index range is sane)

Cheers,

Benoit.