David, On Tue, Feb 8, 2022 at 6:18 AM David Chisnall <gnus...@theravensnest.org> wrote:
> 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). > Ok. 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. > Very cool. > 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. ;) Yours, GC -- Gregory Casamento GNUstep Lead Developer / OLC, Principal Consultant http://www.gnustep.org - http://heronsperch.blogspot.com https://www.patreon.com/bePatron?u=352392 - Become a Patron https://gf.me/u/x8m3sx - My GNUstep GoFundMe https://teespring.com/stores/gnustep - Store
