Automated Reference Counting (Was: Disappointed by GNUstep)

[Wolfgang Lux]

Hi Fred,

> Am 06.02.2022 um 19:50 schrieb Fred Kiefer <fredkiefer@gmx.de>:
> 
> Hi Wolfgang,
> 
>> Am 06.02.2022 um 16:30 schrieb Wolfgang Lux <wolfgang.lux@gmail.com>:
>> 
>>> There are bugs in GNUstep and probably there always will be. We don’t get 
>>> enough testing, usage, for GNUstep gun applications, so many bugs may go 
>>> unnoticed for a long time. At least the first bug you mention below is 
>>> something I already fixed on Christmas. I am surprised that you are still 
>>> seeing it. We may be slow at detecting bugs, but many issues get resolved 
>>> shortly after being reported.
>> 
>> maybe I should have spelled it out more clearly. I don't have that much of a 
>> problem in general with my code crashing when I update to the latest version 
>> of the tree, as long as isn't something that could easily be avoided. And 
>> I've spent/wasted too much time debugging memory management related bugs in 
>> Objective-C code (mostly outside the GNUstep libraries) so that I've lost 
>> tolerance for such bugs these days. Therefore, I keep pestering people with 
>> requests to switch to ARC when encountering such bugs.
> 
> Yes, ARC is a real improvement for application code. Not so much for 
> libraries, as GNUstep is. Getting reference counting correct in procedural 
> programming is not too hard in most case, but doing so declaratively just 
> seems easier. You need to be very careful and provide the correct hints for 
> the compiler to sort out things for you. I would expect that a switch here 
> will cost us about two years until we got most of the declarations correct. 
> Still the change would be worthwhile.

I think you're making up an artificial difference here. The rules for reference 
counting are the same for both application and libraries: If you own/use an 
object retain it, once you no longer own/use it (auto)release it. The tricky 
point just is avoiding cyclic references because they will never be released.
But the real problem (usually) starts when programmers start trying to outsmart 
those simple rules by thinking that some object is already retained by some 
other container/instance variable and they can save some extra CPU cycles (plus 
the textual clutter) by omitting the retain/release calls. And I know what I'm 
talking about because I often enough fall prey to this sort of "optimization". 
But, as the issue with NSPopUpButtonCell shows, I'm not the only one. Note that 
there is no semantic reason to use an unretained reference for the 
_selectedItem instance variable.
So for -gui the main issue is managing references between objects and their 
delegates and avoiding cyclic reference between parents and children in the 
view hierarchy. And otherwise not compromising the code by the attempting to 
omit retain/release otherwise. For -base, the difficulty is not so much cyclic 
references, but multithreading. You have to be even more careful about 
retaining objects because -- at least without serious locking, which comes with 
its own set of problems -- you cannot be sure that assumptions that hold at 
entry of a method are still valid at the end. So, in a way I feel its even the 
other way around: In libraries ypu should be very sure about proper management 
of ownership, which is better done automatically, whereas in applications you 
can eventually be more sloppy, for instance when you know that the application 
is single threaded.

Wolfgang