I think Christian means that the actual mechanism of object destruction doesn’t matter - as long as the system follows the same rules (no references to an object leads to its destruction), a developer need not worry about it.
Oh, it REALLY does matter. In an environment where you can choose, it can make a big difference to performance.
In a video editing app I worked on, we found using GC and periodic flushing was the most performant. RC was too slow, and waiting to flush once processing ended, became very slow, as it pushed the app into VM, and at that point… well… Mac SSD speeds were atrocious.
But from the code’s point of view, you’re still just making sure you are properly dropping all references to objects, right? I think that’s what Christian meant. Sure, there are reasons to choose one under-the-hood system or the other, but the over-the-hood code has few changes…? Do tell me if I’m off base here.
in a method
var X as new MyClass
exists until the method is passed, no need for = nil as tim mentioned.
if you use a propertie in a window it stay there until the whole window is removed.
Propertie1 = new MyClass
come along and recover memory
it make sense for long data or pictures that you not hold unused data in memory.
The thing GC can do is cyclic references.
Xojo can resolve these with reference counting.
So we often need to set some things explicitly to nil in close events.
If you like to manually control it, you can collect objects to dispose later in a global array. Then regularly when you want destructors to run, you can empty the array.
Similar to how the auto release pools on macOS and iOS work.
Real time and Video Game devs never use GC systems if possible. They need deterministic performance. They return memory over time not stopping for a big accumulated clean up. A system hiccup probably is the major issue they avoid.
For the curious:
There’s one language called NIM that started with its memory management Garbage Collected. Then complaints started and requests for a change started at some point. Then the guy developing it did something interesting, he refactored the system for a switchable MM system, so people could choose any approach possible now, and write a new one in the future. It’s called Multi-paradigm Memory Management system. Now the preferred modes are ARC and ORC, and ORC the default. ORC is the same as ARC but adds cycle collector (with microseconds time limit and some smart metrics, postponing more clean ups for latter, not pausing the system) on top of it. ARC don’t, it has no cycle collector, but it is more prone to leaks. There are more options (seven, including a “none” option 
) and even tweaks and fine tuning to satisfy the most demanding people. 