LÖVE

raidho36 wrote: ↑Mon Jul 15, 2019 9:41 pm It does counts internal references as strong ones, however it doesn't actually keep them.

I don't understand this.

raidho36 wrote: ↑Mon Jul 15, 2019 9:41 pm Box2D's internal references are not counted as strong ones because then it would be impossible for physics objects to get garbage collected.

I don't follow this logic. If the object is referenced at creation and unreferenced at destruction (e.g. with luaL_ref / luaL_unref), it should be garbage-collectable.

pgimeno wrote: ↑Tue Jul 16, 2019 10:59 am I don't understand this.

I don't follow this logic.

LOVE immediately unrefs the objects that it no longer keeps internal track of (unless they were never tracked in the first place).

Having strong reference internally means that the object will always have at least one strong reference and cannot be removed through garbage collection.

raidho36 wrote: ↑Tue Jul 16, 2019 11:50 am LOVE immediately unrefs the objects that it no longer keeps internal track of (unless they were never tracked in the first place).

Having strong reference internally means that the object will always have at least one strong reference and cannot be removed through garbage collection.

To me, it seems logical that when an object is added to the World hierarchy, a strong Lua reference to it is added as well until said object is removed from the world by whatever means, and that whatever removes it, removes the reference as well.

One way would be having an internal table object with the exact same contents as those returned by World:getBodies() and others for similar functions (Body:getFixtures() and so on). That should be doable.

It could be but, again, this would basically enforce manual memory management in a roundabout way.

Well, to me, having an object that is garbage-collected but not deleted, and that comes back to life when invoked, is a violation of the POLA, as it leads to bugs due to breaking reasonable assumptions, such as my assumption that GC would not happen while the object existed, when I wrote the replacement setUserData function.