[swift-corelibs-dev] Objective-C Foundation vs CoreLibs Foundation

[David Hart]

Would you agree that the first step should be to have the project as a SwiftPM package so that we have a more consistent way to run tests on all platforms? Do you know if SwiftPM is far enough to support swift-corelibs-foundation? I might have a go at it once I finish implementing NSProgress (about half way through I think).

> On 23 May 2016, at 17:59, Tony Parker via swift-corelibs-dev <swift-corelibs-dev at swift.org> wrote:
> 
> Hi David,
> 
>> On May 22, 2016, at 8:15 AM, David Hart via swift-corelibs-dev <swift-corelibs-dev at swift.org> wrote:
>> 
>> Hello,
>> 
>> The discussion we had previously on this mailing list made it quite clear that:
>> 
>> - Objective-C Foundation is the framework that is supposed to be used on all Darwin platforms,
>> - swift-corelibs-foundation will be the Foundation framework for all other platforms,
>> - Both frameworks will evolve slowly together.
> 
> Yup.
> 
>> 
>> Therefore, it makes sense that for code written against Foundation to be portable, the swift-corelibs-foundation APIs and behavior needs to be identical to Darwin Foundation. Hence the following questions?
>> 
>> - Shouldn't we be writing tests in a way so that they can be run against Darwin Foundation and have the CI Server run them? For example: while working on NSProgress, I write a bunch of tests against Darwin Foundation, make sure they pass, then copy-paste them in the CoreLibs project, and fix the implementation until they pass. This makes sure that both APIs are consistent with each other. I was thinking that we ought to automate this and have the CI server test them.
> 
> That would be a great step. This is part of the reason we tried to set up the dependencies of Foundation on XCTest the way we did, and provide the Xcode project file; so we could share tests. I would welcome any help we can get on improving our automation story here.
> 
>> 
>> - How are we planning to reconcile the API differences between both frameworks? For examples, one of my tests will run against CoreLibs but not against Darwin because NSThread.init takes a closure as argument in CoreLibs but a target+selector in Darwin. This is just one example, but I guess they are other inconsistencies elsewhere. This seems to be particularly the case with APIs that rely on the Objective-C runtime.
> 
> These should be marked as “experimental” in the documentation comments. If not, we should do that.
> 
> There are some areas where we just don’t know what to do yet, because of the lack of the ObjC runtime and implicit bridging on Linux. In some of those places we’ve tried to provide a replacement API and mark it as experimental until we can figure out the larger story.
> 
>> In general, I'm starting to worry about the state of Foundation from a portability point of view. Once Swift 3 is released, I want to start writing portable swift code that relies on Foundation. And it seems like this will require a huge amount of #if os() everywhere to cope with the differences.
>> 
>> David
> 
> Our long term goal is to enable developers to do this. I acknowledge that we have a ways to go to get there. I’ve seen an uptick in contributions recently, which gives me hope that we can get closer before the release of Swift 3.
> 
> - Tony
> 
> _______________________________________________
> swift-corelibs-dev mailing list
> swift-corelibs-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev