On 07/02/2022 20:21, Fred Kiefer wrote:
>>> 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.
> What you are describing is about what I wanted to say, but obviously failed to do. Things are a lot easier in an application as you know what you are aiming at. In a library you need to be correct for whatever use case people come up with. Doing that is hard. ARC may be able to help you in most cases. Still you will have to be very careful and you will need a lot more understanding of the implicit semantics. I agree that we should be going that route, we just need to be aware that it is a steep road and we need to be careful. Just as you said.
If anything, ARC is more important for libraries than application code,
for precisely this reason. ARC explicitly defines ownership (strong,
weak, unsafe_unretained) for consumers of a library interface. Things
like delegates become weak references and so this is both explicit in
the API (the AppKit component does not own the delegate) and less error
prone (the reference becomes nil if the object is deallocated).
When Apple moved their Foundation and AppKit implementations to ARC,
they reported that they had less source code, smaller binaries, faster
code, and fewer bugs. The compiler does a lot of the
reference-count-elision things for you and it's easier to define APIs
that return strong references and don't leak, so you can significantly
reduce autorelease pool pressure.
Many years ago, I ran the -base and -gui code through the ARC Migration
Tool (built into clang). I think about half of the code worked with ARC
already, a lot of the files needed some small tweaks. The migration
tool pointed out all of the places where it couldn't do the automatic
translation.
ARC also makes it a lot easier to interop with C++. C++ containers can
store Objective-C object pointers in ARC mode and will treat the retain
/ release calls as copy constructors and destructors. WinObjC made
heavy use of this and the last time I tried it replacing
`NSMutableDictionary` with a thin wrapper around
`std::unordered_map<id>` (with a hash function defined to call `-hash`
and the equality function defined to call `-isEqual:`) it was faster
than GNUstep's implementation in my tests. I didn't try the same thing
with `NSMutableArray` and `std::vector<id>`. I'm told that Apple's
implementations do this: implement the containers in C++, wrap them in
Objective-C (and there are a lot of high-performance C++ containers with
friendly licenses that we could use if the standard library ones aren't
adequate).
This is where we disagree. Are you advocating rewriting NSDictionary and other classes using C++? I think it would be an interesting experiment, but the question is how does this help us at this point? Would the performance increase (if there is one) be enough to justify the effort?
This was a big part of the reason that I gave up contributing to
GNUstep. I could write significantly simpler code that ran faster using
Objective-C++ and ARC than I could without either and GNUstep would not
accept the less-buggy and faster option. Refactoring code to make it
less maintainable so that it could compile with an old compiler and
spending time finding bugs that are impossible by construction with ARC
felt like a complete waste of my time.
Given that Apple is now focused on SwiftUI, GNUstep is so far behind
things like GTK and Qt in completeness,
I wouldn't be so sure. I, personally, have added about 10-15 new classes to GUI as well as enhancements to the code which reads XIB files (brought in by Fred from TestPlant/Keysight's changes). So we are only about 10 classes shy of 10.15 (11 and 12 didn't add any new GUI classes due to Apple's focus on UIKit).
and the license is not one that
I'd choose to use given any alternative,
I agree with you here, I would have chosen MIT. Unfortunately, the LGPL was selected way before even I joined the project. The advantage it does bring, however, is that it forces the people who release software using GNUstep to contribute their changes back. So, it benefits the project in tangible ways... XIB file parsing is one example of this.
I don't imagine that I'd start
contributing again even if GNUstep adopted Objective-C++ and ARC
We are going in the direction of using ARC, certainly. It's a shame to hear you say that you wouldn't contribute due to these personal reasons. Your contributions are appreciated.
but at
least the remaining contributors would be able to achieve more with the
same amount of effort.
Currently, the lack of ARC is slowing us down due to memory issues and such. So, while I will agree with you on that front, I don't think that using C++ to implement things in Foundation/base would serve this goal.
David
I dearly wish you find it in your heart to start contributing again. Your knowledge and talent are always appreciated. The lecture you gave "objectc, not just for macs" is still on my favorites list. ;)