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@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@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:
On Dec 3, 2015, at 3:09 PM, David Hart <david@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@apple.com> wrote:
Hi Jacob,
On Dec 3, 2015, at 2:23 PM, Jacob Bandes-Storch <jtbandes@gmail.com> wrote:
On Thu, Dec 3, 2015 at 2:13 PM, Chris Lattner <clattner@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?
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?
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:
(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. We can take this opportunity to try to make it better for everyone.
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@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@hartbit.com <mailto:david@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@apple.com <mailto:anthony.parker@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:
On Dec 3, 2015, at 3:09 PM, David Hart <david@hartbit.com <mailto:david@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@apple.com <mailto:anthony.parker@apple.com>> wrote:
Hi Jacob,
On Dec 3, 2015, at 2:23 PM, Jacob Bandes-Storch <jtbandes@gmail.com <mailto:jtbandes@gmail.com>> wrote:
On Thu, Dec 3, 2015 at 2:13 PM, Chris Lattner <clattner@apple.com <mailto:clattner@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?
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?
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:
(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 <Issues ¡ apple/swift ¡ GitHub. We can take this opportunity to try to make it better for everyone.
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@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@me.com <mailto:xcvista@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@hartbit.com <mailto:david@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@apple.com <mailto:anthony.parker@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:
On Dec 3, 2015, at 3:09 PM, David Hart <david@hartbit.com <mailto:david@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@apple.com <mailto:anthony.parker@apple.com>> wrote:
Hi Jacob,
On Dec 3, 2015, at 2:23 PM, Jacob Bandes-Storch <jtbandes@gmail.com <mailto:jtbandes@gmail.com>> wrote:
On Thu, Dec 3, 2015 at 2:13 PM, Chris Lattner <clattner@apple.com <mailto:clattner@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?
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?
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:
(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 <Issues ¡ apple/swift ¡ GitHub. We can take this opportunity to try to make it better for everyone.
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@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.
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.
Could you point out five Objective-C Linux libraries (apart from GNU Foundation) that you'd like to use in your Swift projects on Linux? I suspect you can't and that's why I strongly disagree. You only need Objective-C on Apple platforms â and that's not going away.
Maintaining Objective-C interoperability for non-Apple platforms is a very niche aim and could potentially lead to longer development and evolvement process. That's a reasonable tradeoff.
Pozdrawiam â Regards,
Adrian Kashivskyy
¡¡¡
WiadomoĹÄ napisana przez Maxthon Chan <xcvista@me.com> w dniu 04.12.2015, o godz. 11:54:
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@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.
The thing is, I can, in fact, point out a few libraries I would like to use in Swift and as of now you cannot provide it:
GNUstep GUI (AppKit) and UIKit - anything that have GUI in it will need either of those libraries, and GNUstepâs version works perfectly under Linux as well as Windows.
GNUstep GSWeb (WebObjects) and GDL2 (Enterprise Objects Framework) - Web development stack, ainât this your initial intention of allowing Swift to be run on Linux?
GNUstep SimpleWebKit (lightweight Web browser framework, depend on AppKit)
GNUstep Base for Windows (Foundation, but it works under Windows while yours currently donât) - better cross platform capability from the get-go.
And a few other libraries that are nice to have:
CocoaAsyncSocket
Objective-C LINQ
CGIKit (a lightweight replacement for WebObjects) - another Web stack
Also by maintaining Objective-C compatibility means you can free yourself from the burden of maintaining any runtime libraries except the Swift standard library itself, as it would allow you to offload Foundation and all other supporting libraries to other, existing, Objective-C-based projects, like GNUstep.
¡¡¡
On Dec 4, 2015, at 21:39, Adrian Kashivskyy <adrian.kashivskyy@me.com> wrote:
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.
Could you point out five Objective-C Linux libraries (apart from GNU Foundation) that you'd like to use in your Swift projects on Linux? I suspect you can't and that's why I strongly disagree. You only need Objective-C on Apple platforms â and that's not going away.
Maintaining Objective-C interoperability for non-Apple platforms is a very niche aim and could potentially lead to longer development and evolvement process. That's a reasonable tradeoff.
Pozdrawiam â Regards,
Adrian Kashivskyy
WiadomoĹÄ napisana przez Maxthon Chan <xcvista@me.com <mailto:xcvista@me.com>> w dniu 04.12.2015, o godz. 11:54:
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@gmail.com <mailto:alex.blewitt@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.