A more interesting question would be: is Swift designed to ultimately replace Objective-C? If so, baking in compatibility from the outset of the open source version would probably be going in the wrong direction.
Alex > On 4 Dec 2015, at 11:12, ChanMaxthon <xcvi...@me.com> wrote: > > Then just please leave some stub there so communities can plug their own > bridging into Swift gracefully (that is, not as an out-of-tree patch) > > My idea: > > 1) a pure C header file, swift-compat.h describing the interface the > community-provided bridging mechanism should implement besides > objc/runtime.h, objc/message.h and objc/objc-arc.h, and the associated > documentation describing what the community should do, in a even more liberal > license like MIT or 3c/BSD > 2) The build system checking for a compatible, community-provided > libswift-compat.so during compilation and enable the community-provided > bridging mechanism if present. > 3) Compile-time issues can be solved similarly using libswift-repl-compat.so > > When building Swift without a compatible community-provided Foundation > reimplementation present everything here will be built, like what we are > doing here. When building with such a library set and the corresponding > libswift-compat.so present only the Swift standard library will be built, > linking to the community-provided Objective-C runtime (which is also used as > the Swift runtime through the Objective-C bridge) and take advantage of the > community-provided Foundation framework through bridging. > > Sent from my iPhone > > On Dec 4, 2015, at 16:14, David Hart <da...@hartbit.com > <mailto:da...@hartbit.com>> wrote: > >> The improvements to the Objective-C bridge in Swift 3 are definitely >> appreciated but are just cosmetics (they only affect naming). What about the >> fact that NSURL in your example, being an immutable type, would be better >> represented by a value type in Swift? Don't misunderstand me, I applaud the >> fact that corelibs exists, and understand that Foundation has a lot of great >> ideas, but I would have preferred seeing it exist as a community hobby >> project instead of an official Swift project and have the community instead >> concentrate on a core library that embraces value types, generics, >> protocols, etc... >> >> On 04 Dec 2015, at 00:14, Tony Parker <anthony.par...@apple.com >> <mailto:anthony.par...@apple.com>> wrote: >> >>> Hi David, >>> >>> Fundamentally, we believe that the Foundation library is part of Swift. We >>> also believe that it would be a mistake to throw out the many years of >>> experience that it brings with it. In areas where there are impedance >>> mismatches between the existing API and what feels “Swifty”, we can improve >>> the API of Foundation to make it as great to use there as it is in >>> Objective-C. The first step of that is our heavy involvement with the Swift >>> 3 naming guidelines here: >>> >>> https://swift.org/documentation/api-design-guidelines.html >>> <https://swift.org/documentation/api-design-guidelines.html> >>> >>> Hope this helps, >>> - Tony >>> >>>> On Dec 3, 2015, at 3:09 PM, David Hart <da...@hartbit.com >>>> <mailto:da...@hartbit.com>> wrote: >>>> >>>> Hi Tony, >>>> >>>> Like Jacob, I would have preferred a completely original corelibs library >>>> that uses that clean sheet to be as bold in library design as the standard >>>> library is. Why would that direction go against the goal of begin "as >>>> standards compliant as possible”? it would just mean that Apple Platform >>>> developers would have the option of using the Objective-C bridge to talk >>>> to Objective-C Foundation or use the “swifter” corelibs. >>>> >>>> David. >>>> >>>>> On 03 Dec 2015, at 23:33, Tony Parker <anthony.par...@apple.com >>>>> <mailto:anthony.par...@apple.com>> wrote: >>>>> >>>>> Hi Jacob, >>>>> >>>>>> On Dec 3, 2015, at 2:23 PM, Jacob Bandes-Storch <jtban...@gmail.com >>>>>> <mailto:jtban...@gmail.com>> wrote: >>>>>> >>>>>> On Thu, Dec 3, 2015 at 2:13 PM, Chris Lattner <clatt...@apple.com >>>>>> <mailto:clatt...@apple.com>> wrote: >>>>>> >>>>>> As others have surmised, the goal for the Swift Foundation project is to >>>>>> provide a pure-swift implementation (which reuses widely-available C >>>>>> libraries) of important Foundation APIs that do *not* depend on the >>>>>> Objective-C runtime. Reusing GNUstep, Cocotron, or even Apple’s >>>>>> existing Foundation implementation didn’t allow us to achieve those >>>>>> goals, so we didn’t go with those approaches. >>>>>> >>>>>> This is great, but is the goal also to exactly duplicate all the >>>>>> idiosyncrasies of the Obj-C Foundation? >>>>>> >>>>>> Quiz: what's the result of NSURL(string: "http://one/two;three/four >>>>>> <http://one/two;three/four>")?.URLByAppendingPathComponent("five") ? >>>>>> >>>>>> If, as I would hope, corelibs-foundation is an opportunity to make >>>>>> simpler APIs that resolve some of these weirdnesses, then should the >>>>>> class names (NSURL, NSFileHandle, etc.) really be the same? >>>>>> >>>>>> _______________________________________________ >>>>>> swift-corelibs-dev mailing list >>>>>> swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org> >>>>>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev >>>>>> <https://lists.swift.org/mailman/listinfo/swift-corelibs-dev> >>>>> >>>>> I think NSURL is actually a pretty great example of an API that we want >>>>> to be the same on all platforms. There is quite a bit of logic backing it >>>>> (along with something like NSURLComponents). Check out some of it here: >>>>> >>>>> https://github.com/apple/swift-corelibs-foundation/blob/master/CoreFoundation/URL.subproj/CFURLComponents_URIParser.c >>>>> >>>>> <https://github.com/apple/swift-corelibs-foundation/blob/master/CoreFoundation/URL.subproj/CFURLComponents_URIParser.c> >>>>> >>>>> (and that CF code is reflected up into NSURLComponents) >>>>> >>>>> It’s tricky stuff, and the goal is to get it as standards compliant as >>>>> possible. If we use this implementation for all Swift clients then we can >>>>> get a consistent answer everywhere - and even better, fix bugs everywhere >>>>> at the same time. >>>>> >>>>> So if you find some of the interface confusing (or wrong), then file a >>>>> bug for us at bugs.swift.org <http://bugs.swift.org/>. We can take this >>>>> opportunity to try to make it better for everyone. >>>>> >>>>> Thanks, >>>>> - Tony >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> swift-corelibs-dev mailing list >>>>> swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org> >>>>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev >>>>> <https://lists.swift.org/mailman/listinfo/swift-corelibs-dev> >>> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolut...@swift.org <mailto:swift-evolut...@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> > _______________________________________________ > swift-evolution mailing list > swift-evolut...@swift.org <mailto:swift-evolut...@swift.org> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-corelibs-dev mailing list swift-corelibs-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
