Some of this topic I am unqualified to comment on but I will try to address some of the concerns.
With the goal of matching the surface area of APIs and behavior that are important for cross platform development we can get very close no matter the backing language. In the areas that are potentially unknowns please feel free to ask questions for how things should be implemented or even questions of how the objective-c version works. Those types of discussions are absolutely fair game (to the most nitty gritty details). For your example of NSSortDescriptor: that does have the reliance upon KVC and selectors which swift really does not have the introspection to do the KVC (beyond perhaps some simple cases) and selectors are not really a thing; we would have to change the API. KVC and KVO both were cut from the initial swift-corelibs implementation because we thought that they would not be something that could easily be implemented in Swift without features like property behaviors or other compiler/runtime support (and from swift-evolution there have been some discussions about even expressing key paths as something less stringy). Would NSSortDescriptor be something that would be worthwhile to have if lets say it didn’t have selectors? Would it make sense as an implementation with generics to transact upon a protocol? Does it make sense as a reference type? Should it transact upon NSArray or Array? Changing API is fair game, if there is something that you think is worth bringing to the table as a more swift friendly interface that would help all platforms (and perhaps even make the objc version better too). And we should discuss on what is the best path forward on those types of changes since some of the parties involved may span beyond those that work on the open source side of things. The swift-corelibs-foundation definitely could use some performance boosts (I know for example the JSON and plist serialization implementations have some distinct bottlenecks) but I think our initial goals should be to get the surface area covered first and then after we can verify the behavior then performance optimizations can be made. > On Apr 14, 2016, at 5:57 AM, Kiel Gillard via swift-corelibs-dev > <swift-corelibs-dev@swift.org> wrote: > > 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 > <mailto:alexan...@alemayhu.com>> wrote: > >> >>> On 14 Apr 2016, at 02:32, Kiel Gillard via swift-corelibs-dev >>> <swift-corelibs-dev@swift.org <mailto: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 >> >> <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
_______________________________________________ swift-corelibs-dev mailing list swift-corelibs-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
