Re: Which ObjC2.0 features are missing in the latest GCC?

[Maxthon Chan]

AppKit on CoreAnimation can be our first big piece of fully ARC code. I don’t think anything in AppKit would require special memory handling, so it should be able to be fully ARC'd. Just by enabling ARC and @properties we get a lot of potential bugs out of the system.

Actually if UIKit is in the plans, before working on AppKit I would suggest working on SwiftUI first (at least a Objective-C based subset of it that can result in the correct Swift interface when we get Swift interworking) and build AppKit and UIKit on top of that. (This is like Apple using CoreFoundation as a common denominator between Carbon and Foundation, I am suggesting using a partial SwiftUI as the common denominator between AppKit and UIKit.)

Also if we get that improved C++ support, we can start working on a better IDE and build system that is comparable to Xcode. Modern Xcode uses libclang and libllvm for code highlighting and code sensing, so that is why Objective-C++ is needed, and it is also a huge piece of ARC code (Apple made a point when they converted Xcode from GC to ARC in Xcode 5.) As of our replacement xcode-build and IDEKit (the library parsing xcodeproj bundles) that can also be a huge piece of ARC code.

And there is Swift interworking since I mentioned SwiftUI, which requires clang.

On Nov 26, 2019, at 11:15 PM, Ivan Vučica <ivan@vucica.net> wrote:

On Tue 26 Nov 2019 at 14:43, Pirmin Braun <pb@busw.de> wrote:

a modern Objective-C Ecosystem, comparable to iOS and XCode from Apple, the well known market leader, blah blah

making it a perfect porting target for iOS applications to run on any cheap laptop with any Linux distribution

Correctly implemented library compatible-with-UIKit is a massive undertaking. Switching compilers won’t fix this or speed it up greatly. 

It might attract new people who would more easily take a look at it, but, honestly, given the amount of effort, MRC is comparably not going to be the problem here.

Core Animation-compatible implementation needs more work, as does Opal (Core Graphics). And if you just want to do what was planned years ago — adapt Chameleon to GNUstep’s AppKit — you still need to finish the CA-AppKit integration work.

These things are not enabled by switching to Clang, they are possible with GCC with similar amount of effort as working in a possible Clang fork. Only one thing comes to mind that is enabled by Clang+libobjc2: @dynamic properties in Core Animation (but, only if you care about @dynamic animatable properties being done well).

So let’s not drag iOS into the story. ARC, ObjC++ and other language features are what’s addressable here, and whether core GS should allow this.

--

Sent from Gmail Mobile