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@swift.org> wrote: > > Hi David, > >> On May 22, 2016, at 8:15 AM, David Hart via swift-corelibs-dev >> <swift-corelibs-dev@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@swift.org > https://lists.swift.org/mailman/listinfo/swift-corelibs-dev _______________________________________________ swift-corelibs-dev mailing list swift-corelibs-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
