Yes it does. LDB is an interesting exercise in metatables:
__index = function(self, key) return attributestorage[self] and attributestorage[self][key] end,
What that does is if you access dataobject for indexed readout, it gives you the result from the attributestorage (rather than dataobject). That dude got brutally nilled out here:
for i,v in pairs(dataobj) do
self.attributestorage[dataobj][i] = v
dataobj[i] = nil
You see it actually stores the table in attributestorage, which is not what you get when you request a dataobject.
Really the reason why that's there is to allow the name<->dataobj lookup thang, and the dataobj you get and operate on really just serves as a form of identifier and does nothing else.
Certainly one could implement this differently and have dataobjects stay populated, but one has to worry about a dataobj->name lookup. The way people get dataobjects first is indeed from the iterator over them. Then they may want to check names for the ones they support etc.
Alternatively one could try to find a way to store of name within the dataobject, but doing it this way avoids having to reserve a spot for the name within that table hence keeps any keying into that table completely flexible.
Anyway, the dataobj is indeed empty in LDB1.1 if you use the standard table iterator on it. But because of the metatabling indexing will work fine. There is a lib iterator to allow you to do the standard iteration if you need that.
Thank you (both).
Tekkub already pointed me to the lib iterator, though I really don't need it.
I could just not anderstand why an "How is there?" does not work, but an "Are YOU there" does.
Not with lua's current metatables. Callbacks would never fire when changing an existing index. We have __newindex, but no __changedindex. Hence the need for a proxy metatable.
Meh that darn thing gets me every time. Ref manual reads:
"newindex": The indexing assignment table[key] = value.
giving the impression that newindex is called for all indexing assignments.
But yeah it has this in the implementation of what it actually does:
if type(table) == "table" then
local v = rawget(table, key)
if v ~= nil then rawset(table, key, value); return end
before ever accessing the __newindex metatable.
Anyone knows why this is? Makes no real sense to me to separate new and changed assignments like this for meta calls. The metatable function itself could reject non-nil keys if it wanted to so why hardcode this behavior when it makes generic assignment inaccessible?