[swift-corelibs-dev] [swift-evolution] Proposal: Swift Open Source Project and Foundation replacements

Maxthon Chan xcvista at me.com
Fri Dec 4 04:50:28 CST 2015 

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.blewitt at 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 <xcvista at me.com <mailto:xcvista at 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 <david at hartbit.com <mailto:david at 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.parker at apple.com <mailto:anthony.parker at 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 <david at hartbit.com <mailto:david at 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.parker at apple.com <mailto:anthony.parker at apple.com>> wrote:
>>>>>> 
>>>>>> Hi Jacob,
>>>>>> 
>>>>>>> On Dec 3, 2015, at 2:23 PM, Jacob Bandes-Storch <jtbandes at gmail.com <mailto:jtbandes at gmail.com>> wrote:
>>>>>>> 
>>>>>>> On Thu, Dec 3, 2015 at 2:13 PM, Chris Lattner <clattner at apple.com <mailto:clattner at 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 at swift.org <mailto:swift-corelibs-dev at 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 at swift.org <mailto:swift-corelibs-dev at 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-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>  _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-corelibs-dev/attachments/20151204/528a5fd6/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4097 bytes
Desc: not available
URL: <https://lists.swift.org/pipermail/swift-corelibs-dev/attachments/20151204/528a5fd6/attachment-0001.p7s>

More information about the swift-corelibs-dev mailing list