Thanks for the reply and for pointing me to the design document. I doubt that Foundation's dependency on the exclusive features of the Objective-C runtime would be so instrumental to the majority of its implementation details. I doubt things like algorithms and performance optimisations used in Foundation are each and every time exclusive to the ObjC runtime such that it justifies building a pure Swift implementation without respect to its ancestor. Perennial problems in computer science have their solutions in a variety of languages and runtimes. So even if a solution is dependent on the ObjC runtime, there may be a spiritual sibling to a solution.
For a simple example, I figured my first small contribution could be to the implementation of NSSortDescriptor. The API seems straightforward and doesn't suggest there's anything exclusive to the ObjC runtime (eg swizzling) going on. So if I was to provide most of this implementation, I would be doing so in the dark of any learnings from its release history. Perhaps I need to suppress my sceptical feelings, trust Apple are making the right decision here (because, you know, given they are the ones privy to the source code!) and have faith that Apple won't eventually replace Foundation with a buggy and underperforming equivalent for Swift developers. But I am concerned for the quality of the platform and I desire to give the community the best work I can. I would like to know what the error in my concern is and if others in the community share this concern. Kiel Sent from my iPhone > On 14 Apr 2016, at 9:11 PM, Alexander Alemayhu <alexan...@alemayhu.com> wrote: > > >> On 14 Apr 2016, at 02:32, Kiel Gillard via swift-corelibs-dev >> <swift-corelibs-dev@swift.org> wrote: >> >> Hello all, > > Hei, > >> >> I’m considering contributing yet part of me feels hesitant or reluctant to >> do so because I do not want to do a poor job at what feels like I’d be >> reverse-engineering the Foundation APIs (as opposed to Core Foundation and >> the pure Swift Foundation). > > Cool, I also want to contribute :) > >> >> Perhaps I missed the answer somewhere else or maybe I’m lacking the >> imagination to come up with reasons myself, but why isn’t Foundation (as it >> ships in iOS and OS X now) open source, too? >> >> Wouldn’t a pure Swift implementation of Foundation benefit from insights >> from the implementation details of Foundation? For example, Foundation may >> have implemented such-and-such an API in a particular way for performance >> reasons that would be unacceptable if released. That insight may be lost by >> providing a Swift implementation of an API that merely reproduces the same >> output from the same input. Concretely speaking, I seem to recall such a >> conversation a few months ago or so with respect to the implementation >> NSJSONSerialization (unfortunately, I can’t seem to find the thread). >> >> I’m not suggesting a pure Swift Foundation should be a one-to-one port of >> Foundation’s implementation, but surely it would be helpful (not just for >> me, but for others too) to take the learnings of a mature API into account >> when implementing Swift Foundation? >> >> Thanks, > > > If you haven’t looked at the Design Principles[0] for > swift-corelibs-foundation consider reading it. > > [0]: > https://github.com/apple/swift-corelibs-foundation/blob/master/Docs/Design.md >
_______________________________________________ swift-corelibs-dev mailing list swift-corelibs-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
