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
