I would just like to politely argue that reference counting cannot be considered a form of garbage collection, at all. The discriminating factor is that in a GC world there is, well to put it bluntly, a garbage collector. A garbage collector is a basically a process itself which determines reachability of objects/memory and reclaims that memory if it can determine it is no longer in use. In manual reference counting (ARC also), there is not necessarily such a process. In Objective-C, as soon as an object's reference count gets to zero it's memory is immediately deallocated. There is no process which searches and marks an object's memory to be reclaimed. It would be like calling any other type of manual programatic memory management garbage collection because the programmer handled the garbage. Now, reference counting in Python may use a garbage collector to clean up zero count references, but they are mutually exclusive, IMHO.
> A garbage collector is a basically a process itself which determines reachability of objects/memory and reclaims that memory if it can determine it is no longer in use
That's a very.... narrow definition, to say the least. I've never seen this outside of the objective-c world. In my mind, garbage collection is automatic memory management, of which objective-c provides an arguably better solution than imprecise collectors. To distinguish between them at all strikes me as pedantic and counterproductive.
Anyway, the only real difference between python and objective-c is that yes, python has a garbage collection routine that bulk frees objects with refcounts of 0... functionality conveniently provided by @autorelease. This would make ARC a superset of python's GC.
I'm not here to argue, other than intellectual arguments... You call my definition narrow. Not sure why. Can you describe what a GC does in a single sentence? I'm just going for a simple description. It also doesn't matter if you haven't seen this outside of Obj-C. I am almost lost at the point that is being made. ARC is in no way, at all, a garbage collection technology. @autoreleasepool is in no way a garbage collection concept. All it does is provide a scope for the compiler to inject a 'release' call on all the instances in the block that were sent the autorelease message in said block.
ARC is purely a compile time feature. And an awesome one at that. There is no ARC runtime process/thread. There is no ARC memory manager.
Anyway. Feel free to respond. I have said all I am going to.
On another note, is there any way to be informed/notified that someone responded to a post? Or do you have to keep coming back and checking? I feel that I drop out of conversations because I lose track.
Garbage Collection: A system wherein memory is automatically allocated when referenced and freed for another allocation when not referenced.
It sounds like you believe a garbage collection system must achieve a certain level of complexity beyond reference counting, and I can't help with that—however, it's a fairly pointless distinction if we switch from saying "GC" to "GC and reference counting" to talk about automatic memory management. What does that give us? And why WOULDN'T you want this simplicity? I don't much care how trivial you consider ARC to be, it certainly collects garbage effectively. No memory scans to worry about interrupting your real time application. If you really need to not deallocate in a tight loop you can autorelease (I never claimed it was a garbage collection mechanism).
And I am not aware of a way to be notified by HN itself but a lot of apps and sites provide that. (I don't use one myself, I just check threads I am still interested in.)
