Let’s take a look at C# which Microsoft designed to replace C++ MFC. The compatibility is never removed although C# itself is pretty complete already. During early days (2002) lots of components in C# are stubs calling back to MFC but nevertheless this presented a more or less complete library set to the user and allowed the language to gain traction - so many traction that now people demand it to be ported to multiple platforms.
Removing Objective-C compatibility in Swift (which does not even have a complete set of libraries yet) in this stage would undermine its usability and the completeness of the libraries, and when the project finally matured a bad reputation of “incomplete support” would already be out there, hampering its use. > On Dec 4, 2015, at 18:33, Alex Blewitt <alex.blew...@gmail.com> wrote: > > 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 >> <mailto: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>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ swift-corelibs-dev mailing list swift-corelibs-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
