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.
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.
- 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.
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
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
