How to clean subviews properly?

[definability]

The View class supports subviews.
The method addviews should be used to register new views properly.
How to dynamically remove them? Is it safe to perform view.subviews = {} or is DFHack Lua API missing this part?

[ab9rf]

The entire Lua GUI widget system is implemented in pure Lua and thus ordinary Lua garbage collection will clean any such objects up when they're no longer globally reachable within any active Lua state.

[definability]

Thanks for the prompt reply!

Sure, but the catch (which you mentioned) is significant: there may be other fields that store references to the sub views for some purposes; or even a global overlay manager may store the references.

Hence, my question is more about the conventions or "guarantees". For example, if this was C++ and subviews was a container of unique pointers, I would be sure I can just clean the container to get rid of the views. If subviews was a container of shared pointers, this would be a sign that I must investigate what else can use the sub views.
In Lua, it is a matter of agreement, so I am curious whether there is such an agreement regarding this field.

If the sub views information is not stored anywhere except for the subviews table, it is fine to specify this in the documentation for other users to rely on and other developers to consider, right?

[ab9rf]

Sure, but the catch (which you mentioned) is significant: there may be other fields that store references to the sub views for some purposes; or even a global overlay manager may store the references.

Hence, my question is more about the conventions or "guarantees". For example, if this was C++ and subviews was a container of unique pointers, I would be sure I can just clean the container to get rid of the views. If subviews was a container of shared pointers, this would be a sign that I must investigate what else can use the sub views. In Lua, it is a matter of agreement, so I am curious whether there is such an agreement regarding this field.

If the sub views information is not stored anywhere except for the subviews table, it is fine to specify this in the documentation for other users to rely on and other developers to consider, right?

If such objects are stored elsewhere, then it would be even worse if the original creator actively sought to destroy them while they're still referenced elsewhere. If "a global overlay manager" needs to hold references to such objects, it will do so and when it no longer needs them it will release them and they will be garbage-collected. This is, indeed, a large part of why garbage collected languages use garbage collection as a memory management strategy.

I guess part of the issue here is that I don't understand why you are raising this concern. These are generally not large objects, nor are they generally interacted with in extremely hot loops, and as such I don't understand why we should be terribly concerned about this. They will be disposed of when the Lua global state in which they are embedded is destroyed (which, at the latest, occurs during DFHack shutdown), and so they won't ultimately leak. Can you give me a reason to care enough about the timing of the reclamation of these objects to justify investigating whether they might end up shared by another object?

[definability]

If such objects are stored elsewhere, then it would be even worse if the original creator actively sought to destroy them while they're still referenced elsewhere. If "a global overlay manager" needs to hold references to such objects [...]

Yes, this is my primary concern and the reason I expected clearviews when I saw the method addviews.

Can you give me a reason to care enough about the timing of the reclamation of these objects to justify investigating whether they might end up shared by another object?

Suppose (just for example) I create an overlay where it is easier to clean subviews than edit them.
Let them also use the shared resources of my module when they are active.
In this case, it is crucial to make sure that neither of their listeners is called after I perform self.subviews = {}.

How this may happen: Imagine somebody implementing (or has already done one) caching of the most frequently used views in the DFHack overlay manager. Currently, the documentation does not promise users it will not happen — there is only the addviews method and no mentions of non-caching elsewhere.
If this were the case, my imaginary subviews would still be visible if I tried to dispose of them just with self.subviews = {}. Technically, it would not be the library's bug, but my misuse of it.

Of course, anybody can delve into the source code to find out whether it is safe to simply clear the table, but I still cannot be sure whether somebody plans to cache the subviews elsewhere. The "guarantees" would be either:

1. Talking to a maintainer like you to find out that the script developers rely on self.subviews = {}, so this is remembered, and the correctness of such a cleanup approach will be preserved.
2. Finding in documentation "To dispose of the subviews, you can use self.subviews = {}.
3. Having a function self.clearviews() and not being bothered by what it does.

[ab9rf]

So the question I have now is "why didn't you lead with this?" but you don't need to answer it but I would like for you to think about whether this was an efficient way to engage in this discussion.

[definability]

So the question I have now is "why didn't you lead with this?" but you don't need to answer it but I would like for you to think about whether this was an efficient way to engage in this discussion.

I did not mean to offend you, and I sincerely appreciate your time and experience.
I just wanted to know how to clean the subviews, considering your knowledge of the DFHack codebase, which I obviously lack.

My current conclusion from the dialogue is that it is idiomatically correct (from the Lua and DFHack API perspectives) to dispose of subviews using self.subviews = {}. Hence, I can add this to the documentation for other users to rely on such behaviour unless they mess with subviews in their implementations of overlays.