Issues Regarding the Deallocation of `Table` and `TableModel`

[kojix2]

Crystal is a garbage-collected language, and in general, explicit memory management is discouraged.

However, the mutual references between Table and TableModel complicate this.

In terms of ownership, the structure is typically:
Window → Box → Table → TableModel.
That is, a Table owns its TableModel. In practice, though, a TableModel may be shared across multiple Table instances. For proper cleanup, the TableModel should only be released after all associated Table instances have been destroyed. This requirement contradicts intuition—normally, destruction would proceed in the opposite direction of reference: TableModel → Table → Box → Window.

To deallocate a Table, it must first be removed from its parent Box. Therefore, the correct order is:
first, remove the Table from the Box; then explicitly destroy the Table; and finally deallocate the TableModel.

This kind of manual management is cumbersome. Ideally, it should be handled by the garbage collector via finalize, but this is often incompatible with libui due to the non-deterministic nature of GC timing.