Proposal: Swift Open Source Project and Foundation replacements


(ChanMaxthon) #1

Dear Swift developers:

Maybe you have never heard of it, but there have been several ongoing efforts, like GNUstep and Cocotron, at maintaining an open source Foundation reimplementation for alternative operating systems like Linux. It seemed to me that the current release of Swift did not put such efforts into consideration and brutally broke compatibility between Swift and Objective-C on Linux. I understand the fact that Apple is unwilling to release source code of Foundation, and this is usually where those alternative implementations comes into play.

Some of such projects, like GNUstep, are mature enough to allow existing AppKit applications written in Objective-C, like TextEdit and Chess, to be ported from OS X to Linux and Windows without changing too much, if any, code, taking all modern Objective-C features like ARC and object subscripting with stride, with a compatible version of LLVM compiler. Meanwhile, with the current version of Swift, even if the Swift code is written with calls to Objective-C runtime assuming the case on OS X, it is broken under Linux even with libobjc linked in.

I am here suggesting keeping the Objective-C bridge intact at least when built with a compatible version of libobjc (and GNUstep project have one already.) This will allow users of such alternative Foundation reimplementations to use their favourite Foundation distribution in place of the version provided by the Swift project, retaining the code compatibility already established between OS X and Linux by those Swift reimplementations.

In such an environment the alternative Foundation implementation will provide their own version of CoreFoundation and Foundation, implemented using C and Objective-C, as well as a libobjc that supports ARC. The Swift environment would be built without its own CoreFoundation and Foundation, but linking against the provided version instead, bridging calls just like OS X version of Swift does. This will also allow the new Swift platform to take full advantage of the AppKit came with the alternative Foundation, allow porting full OS X apps to Linux a lot easier. The above also applies for porting iOS apps, if the alternative Foundation implementation also comes with their own UIKit.

Max


(Chris Lattner) #2

Dear Swift developers:

Maybe you have never heard of it, but there have been several ongoing efforts, like GNUstep and Cocotron, at maintaining an open source Foundation reimplementation for alternative operating systems like Linux. It seemed to me that the current release of Swift did not put such efforts into consideration and brutally broke compatibility between Swift and Objective-C on Linux. I understand the fact that Apple is unwilling to release source code of Foundation, and this is usually where those alternative implementations comes into play.

Hi Maxthon,

Thanks for your interest, we’re definitely aware of GNUstep and Cocotron.

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.

We’re aware that this means that it will take longer for the Swift Foundation to be fully operational and useful, but that is a tradeoff we’re willing to make. You are of course welcome to make Swift work with GNUstep or Cocotron if you’re interested in doing that, but that seems outside the charter of the work on Swift Foundation.

-Chris

···

On Dec 3, 2015, at 12:01 PM, Maxthon Chan <xcvista@me.com> wrote:

Some of such projects, like GNUstep, are mature enough to allow existing AppKit applications written in Objective-C, like TextEdit and Chess, to be ported from OS X to Linux and Windows without changing too much, if any, code, taking all modern Objective-C features like ARC and object subscripting with stride, with a compatible version of LLVM compiler. Meanwhile, with the current version of Swift, even if the Swift code is written with calls to Objective-C runtime assuming the case on OS X, it is broken under Linux even with libobjc linked in.

I am here suggesting keeping the Objective-C bridge intact at least when built with a compatible version of libobjc (and GNUstep project have one already.) This will allow users of such alternative Foundation reimplementations to use their favourite Foundation distribution in place of the version provided by the Swift project, retaining the code compatibility already established between OS X and Linux by those Swift reimplementations.

In such an environment the alternative Foundation implementation will provide their own version of CoreFoundation and Foundation, implemented using C and Objective-C, as well as a libobjc that supports ARC. The Swift environment would be built without its own CoreFoundation and Foundation, but linking against the provided version instead, bridging calls just like OS X version of Swift does. This will also allow the new Swift platform to take full advantage of the AppKit came with the alternative Foundation, allow porting full OS X apps to Linux a lot easier. The above also applies for porting iOS apps, if the alternative Foundation implementation also comes with their own UIKit.

Max_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev


(Jacob Bandes-Storch) #3

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")?.
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?

···

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.


(Tony Parker) #4

Hi Jacob,

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")?.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
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

(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.

Thanks,
- Tony

···

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 <mailto:clattner@apple.com>> wrote:


(Jacob Bandes-Storch) #5

Thanks, Tony.

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.

Agreed. I look forward to it :slight_smile: I'm just concerned that users will expect
behavior to exactly match their equivalent Obj-C code. If these bugs are
fixed / APIs are refined in corelibs-foundation, that expectation might be
broken.

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.

Will do!

···

On Thu, Dec 3, 2015 at 2:33 PM, Tony Parker <anthony.parker@apple.com> wrote:


(Tony Parker) #6

Thanks, Tony.

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.

Agreed. I look forward to it :slight_smile: I'm just concerned that users will expect behavior to exactly match their equivalent Obj-C code. If these bugs are fixed / APIs are refined in corelibs-foundation, that expectation might be broken.

Indeed, a very good point and something we are actively thinking about.

An important goal of our project is to provide a layer of OS independence and portability. There may be times when we have a bug in the Obj-C implementation that we therefore decide to reflect in the Swift implementation as well, because the inconsistency would otherwise be a problem. Hopefully this doesn’t happen too often. I’d rather fix the bug in the Obj-C implementation as well, but there are always going to be tradeoffs to make.

We have lots of experience making changes to Foundation underneath apps and keeping things compatible. I think we’ll certainly be using some of that as we move forward with the Swift Foundation implementation as well. For example, we may choose to deprecate a confusing (or wrong) API and replace it with something better. We’d like the bar for changing API to be very high, though, so that we can provide as much stability to clients as possible.

Thanks,
- Tony

···

On Dec 3, 2015, at 2:37 PM, Jacob Bandes-Storch <jtbandes@gmail.com> wrote:
On Thu, Dec 3, 2015 at 2:33 PM, Tony Parker <anthony.parker@apple.com <mailto:anthony.parker@apple.com>> wrote:

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.

Will do!


(Gregory Casamento) #7

David,

There wouldn't be any need to do it for every platform. There is one
objective-C runtime GNUstep uses for every platform it runs on. So there
is no need for it to be different.

Reimplementing everything in pure swift is silly because it would not allow
re-use of all of the objective-c that is out there which is one of the
advantages of swift in the first place.

GC

···

On Thu, Dec 3, 2015 at 3:32 PM, David Hart <david@hartbit.com> wrote:

I also agree with Adrian. I would much prefer to see efforts put towards
implementing a pure Swift foundation API than supporting a Cocoa
implementation and bridge on every platform Swift will run on.

On 03 Dec 2015, at 21:01, Gregory Casamento <greg.casamento@gmail.com> > wrote:

Way ahead of you
On Thu, Dec 3, 2015 at 15:01 Maxthon Chan <xcvista@me.com> wrote:

Dear Swift developers:

Maybe you have never heard of it, but there have been several ongoing
efforts, like GNUstep and Cocotron, at maintaining an open source
Foundation reimplementation for alternative operating systems like Linux.
It seemed to me that the current release of Swift did not put such efforts
into consideration and brutally broke compatibility between Swift and
Objective-C on Linux. I understand the fact that Apple is unwilling to
release source code of Foundation, and this is usually where those
alternative implementations comes into play.

Some of such projects, like GNUstep, are mature enough to allow existing
AppKit applications written in Objective-C, like TextEdit and Chess, to be
ported from OS X to Linux and Windows without changing too much, if any,
code, taking all modern Objective-C features like ARC and object
subscripting with stride, with a compatible version of LLVM compiler.
Meanwhile, with the current version of Swift, even if the Swift code is
written with calls to Objective-C runtime assuming the case on OS X, it is
broken under Linux even with libobjc linked in.

I am here suggesting keeping the Objective-C bridge intact at least when
built with a compatible version of libobjc (and GNUstep project have one
already.) This will allow users of such alternative Foundation
reimplementations to use their favourite Foundation distribution in place
of the version provided by the Swift project, retaining the code
compatibility already established between OS X and Linux by those Swift
reimplementations.

In such an environment the alternative Foundation implementation will
provide their own version of CoreFoundation and Foundation, implemented
using C and Objective-C, as well as a libobjc that supports ARC. The Swift
environment would be built without its own CoreFoundation and Foundation,
but linking against the provided version instead, bridging calls just like
OS X version of Swift does. This will also allow the new Swift platform to
take full advantage of the AppKit came with the alternative Foundation,
allow porting full OS X apps to Linux a lot easier. The above also applies
for porting iOS apps, if the alternative Foundation implementation also
comes with their own UIKit.

Max_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Gregory Casamento
GNUstep Lead Developer / OLC, Principal Consultant
http://www.gnustep.org - http://heronsperch.blogspot.com
http://ind.ie/phoenix/


(Gregory Casamento) #8

Additionally, GNUstep is a Nearly complete clone of cocoa that is well
tested and mature. Building a Cocoa-inspired Swift implementation would,
quite honestly, miss the point entirely.

GC

···

On Thu, Dec 3, 2015 at 3:37 PM, Gregory Casamento <greg.casamento@gmail.com> wrote:

David,

There wouldn't be any need to do it for every platform. There is one
objective-C runtime GNUstep uses for every platform it runs on. So there
is no need for it to be different.

Reimplementing everything in pure swift is silly because it would not
allow re-use of all of the objective-c that is out there which is one of
the advantages of swift in the first place.

GC

On Thu, Dec 3, 2015 at 3:32 PM, David Hart <david@hartbit.com> wrote:

I also agree with Adrian. I would much prefer to see efforts put towards
implementing a pure Swift foundation API than supporting a Cocoa
implementation and bridge on every platform Swift will run on.

On 03 Dec 2015, at 21:01, Gregory Casamento <greg.casamento@gmail.com> >> wrote:

Way ahead of you
On Thu, Dec 3, 2015 at 15:01 Maxthon Chan <xcvista@me.com> wrote:

Dear Swift developers:

Maybe you have never heard of it, but there have been several ongoing
efforts, like GNUstep and Cocotron, at maintaining an open source
Foundation reimplementation for alternative operating systems like Linux.
It seemed to me that the current release of Swift did not put such efforts
into consideration and brutally broke compatibility between Swift and
Objective-C on Linux. I understand the fact that Apple is unwilling to
release source code of Foundation, and this is usually where those
alternative implementations comes into play.

Some of such projects, like GNUstep, are mature enough to allow existing
AppKit applications written in Objective-C, like TextEdit and Chess, to be
ported from OS X to Linux and Windows without changing too much, if any,
code, taking all modern Objective-C features like ARC and object
subscripting with stride, with a compatible version of LLVM compiler.
Meanwhile, with the current version of Swift, even if the Swift code is
written with calls to Objective-C runtime assuming the case on OS X, it is
broken under Linux even with libobjc linked in.

I am here suggesting keeping the Objective-C bridge intact at least when
built with a compatible version of libobjc (and GNUstep project have one
already.) This will allow users of such alternative Foundation
reimplementations to use their favourite Foundation distribution in place
of the version provided by the Swift project, retaining the code
compatibility already established between OS X and Linux by those Swift
reimplementations.

In such an environment the alternative Foundation implementation will
provide their own version of CoreFoundation and Foundation, implemented
using C and Objective-C, as well as a libobjc that supports ARC. The Swift
environment would be built without its own CoreFoundation and Foundation,
but linking against the provided version instead, bridging calls just like
OS X version of Swift does. This will also allow the new Swift platform to
take full advantage of the AppKit came with the alternative Foundation,
allow porting full OS X apps to Linux a lot easier. The above also applies
for porting iOS apps, if the alternative Foundation implementation also
comes with their own UIKit.

Max_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Gregory Casamento
GNUstep Lead Developer / OLC, Principal Consultant
http://www.gnustep.org - http://heronsperch.blogspot.com
http://ind.ie/phoenix/

--
Gregory Casamento
GNUstep Lead Developer / OLC, Principal Consultant
http://www.gnustep.org - http://heronsperch.blogspot.com
http://ind.ie/phoenix/


(Gregory Casamento) #9

Way ahead of you

···

On Thu, Dec 3, 2015 at 15:01 Maxthon Chan <xcvista@me.com> wrote:

Dear Swift developers:

Maybe you have never heard of it, but there have been several ongoing
efforts, like GNUstep and Cocotron, at maintaining an open source
Foundation reimplementation for alternative operating systems like Linux.
It seemed to me that the current release of Swift did not put such efforts
into consideration and brutally broke compatibility between Swift and
Objective-C on Linux. I understand the fact that Apple is unwilling to
release source code of Foundation, and this is usually where those
alternative implementations comes into play.

Some of such projects, like GNUstep, are mature enough to allow existing
AppKit applications written in Objective-C, like TextEdit and Chess, to be
ported from OS X to Linux and Windows without changing too much, if any,
code, taking all modern Objective-C features like ARC and object
subscripting with stride, with a compatible version of LLVM compiler.
Meanwhile, with the current version of Swift, even if the Swift code is
written with calls to Objective-C runtime assuming the case on OS X, it is
broken under Linux even with libobjc linked in.

I am here suggesting keeping the Objective-C bridge intact at least when
built with a compatible version of libobjc (and GNUstep project have one
already.) This will allow users of such alternative Foundation
reimplementations to use their favourite Foundation distribution in place
of the version provided by the Swift project, retaining the code
compatibility already established between OS X and Linux by those Swift
reimplementations.

In such an environment the alternative Foundation implementation will
provide their own version of CoreFoundation and Foundation, implemented
using C and Objective-C, as well as a libobjc that supports ARC. The Swift
environment would be built without its own CoreFoundation and Foundation,
but linking against the provided version instead, bridging calls just like
OS X version of Swift does. This will also allow the new Swift platform to
take full advantage of the AppKit came with the alternative Foundation,
allow porting full OS X apps to Linux a lot easier. The above also applies
for porting iOS apps, if the alternative Foundation implementation also
comes with their own UIKit.

Max_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev


(Adrian Kashivskyy) #10

I believe the goal of swift-corelibs-foundation is to fully reimplement Foundation functionality in pure, platform-agnostic Swift, so that no bridging is required (at least on Linux). Maintaining Objective-C interoperability on Linux would be a too huge task at the current stage, in my opinion.

Pozdrawiam – Regards,
Adrian Kashivskyy

···

Wiadomość napisana przez Maxthon Chan <xcvista@me.com> w dniu 03.12.2015, o godz. 21:01:

Dear Swift developers:

Maybe you have never heard of it, but there have been several ongoing efforts, like GNUstep and Cocotron, at maintaining an open source Foundation reimplementation for alternative operating systems like Linux. It seemed to me that the current release of Swift did not put such efforts into consideration and brutally broke compatibility between Swift and Objective-C on Linux. I understand the fact that Apple is unwilling to release source code of Foundation, and this is usually where those alternative implementations comes into play.

Some of such projects, like GNUstep, are mature enough to allow existing AppKit applications written in Objective-C, like TextEdit and Chess, to be ported from OS X to Linux and Windows without changing too much, if any, code, taking all modern Objective-C features like ARC and object subscripting with stride, with a compatible version of LLVM compiler. Meanwhile, with the current version of Swift, even if the Swift code is written with calls to Objective-C runtime assuming the case on OS X, it is broken under Linux even with libobjc linked in.

I am here suggesting keeping the Objective-C bridge intact at least when built with a compatible version of libobjc (and GNUstep project have one already.) This will allow users of such alternative Foundation reimplementations to use their favourite Foundation distribution in place of the version provided by the Swift project, retaining the code compatibility already established between OS X and Linux by those Swift reimplementations.

In such an environment the alternative Foundation implementation will provide their own version of CoreFoundation and Foundation, implemented using C and Objective-C, as well as a libobjc that supports ARC. The Swift environment would be built without its own CoreFoundation and Foundation, but linking against the provided version instead, bridging calls just like OS X version of Swift does. This will also allow the new Swift platform to take full advantage of the AppKit came with the alternative Foundation, allow porting full OS X apps to Linux a lot easier. The above also applies for porting iOS apps, if the alternative Foundation implementation also comes with their own UIKit.

Max_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(David Hart) #11

I also agree with Adrian. I would much prefer to see efforts put towards implementing a pure Swift foundation API than supporting a Cocoa implementation and bridge on every platform Swift will run on.

···

Sent from my iPhone

On 03 Dec 2015, at 21:01, Gregory Casamento <greg.casamento@gmail.com> wrote:

Way ahead of you

On Thu, Dec 3, 2015 at 15:01 Maxthon Chan <xcvista@me.com> wrote:
Dear Swift developers:

Maybe you have never heard of it, but there have been several ongoing efforts, like GNUstep and Cocotron, at maintaining an open source Foundation reimplementation for alternative operating systems like Linux. It seemed to me that the current release of Swift did not put such efforts into consideration and brutally broke compatibility between Swift and Objective-C on Linux. I understand the fact that Apple is unwilling to release source code of Foundation, and this is usually where those alternative implementations comes into play.

Some of such projects, like GNUstep, are mature enough to allow existing AppKit applications written in Objective-C, like TextEdit and Chess, to be ported from OS X to Linux and Windows without changing too much, if any, code, taking all modern Objective-C features like ARC and object subscripting with stride, with a compatible version of LLVM compiler. Meanwhile, with the current version of Swift, even if the Swift code is written with calls to Objective-C runtime assuming the case on OS X, it is broken under Linux even with libobjc linked in.

I am here suggesting keeping the Objective-C bridge intact at least when built with a compatible version of libobjc (and GNUstep project have one already.) This will allow users of such alternative Foundation reimplementations to use their favourite Foundation distribution in place of the version provided by the Swift project, retaining the code compatibility already established between OS X and Linux by those Swift reimplementations.

In such an environment the alternative Foundation implementation will provide their own version of CoreFoundation and Foundation, implemented using C and Objective-C, as well as a libobjc that supports ARC. The Swift environment would be built without its own CoreFoundation and Foundation, but linking against the provided version instead, bridging calls just like OS X version of Swift does. This will also allow the new Swift platform to take full advantage of the AppKit came with the alternative Foundation, allow porting full OS X apps to Linux a lot easier. The above also applies for porting iOS apps, if the alternative Foundation implementation also comes with their own UIKit.

Max_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(David Hart) #12

I also agree with Adrian. I would much prefer to see efforts put towards implementing a pure Swift foundation API than supporting a Cocoa implementation and bridge on every platform Swift will run on.

···

On 03 Dec 2015, at 21:01, Gregory Casamento <greg.casamento@gmail.com> wrote:

Way ahead of you

On Thu, Dec 3, 2015 at 15:01 Maxthon Chan <xcvista@me.com> wrote:
Dear Swift developers:

Maybe you have never heard of it, but there have been several ongoing efforts, like GNUstep and Cocotron, at maintaining an open source Foundation reimplementation for alternative operating systems like Linux. It seemed to me that the current release of Swift did not put such efforts into consideration and brutally broke compatibility between Swift and Objective-C on Linux. I understand the fact that Apple is unwilling to release source code of Foundation, and this is usually where those alternative implementations comes into play.

Some of such projects, like GNUstep, are mature enough to allow existing AppKit applications written in Objective-C, like TextEdit and Chess, to be ported from OS X to Linux and Windows without changing too much, if any, code, taking all modern Objective-C features like ARC and object subscripting with stride, with a compatible version of LLVM compiler. Meanwhile, with the current version of Swift, even if the Swift code is written with calls to Objective-C runtime assuming the case on OS X, it is broken under Linux even with libobjc linked in.

I am here suggesting keeping the Objective-C bridge intact at least when built with a compatible version of libobjc (and GNUstep project have one already.) This will allow users of such alternative Foundation reimplementations to use their favourite Foundation distribution in place of the version provided by the Swift project, retaining the code compatibility already established between OS X and Linux by those Swift reimplementations.

In such an environment the alternative Foundation implementation will provide their own version of CoreFoundation and Foundation, implemented using C and Objective-C, as well as a libobjc that supports ARC. The Swift environment would be built without its own CoreFoundation and Foundation, but linking against the provided version instead, bridging calls just like OS X version of Swift does. This will also allow the new Swift platform to take full advantage of the AppKit came with the alternative Foundation, allow porting full OS X apps to Linux a lot easier. The above also applies for porting iOS apps, if the alternative Foundation implementation also comes with their own UIKit.

Max_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(David Hart) #13

GC,

I just went to check the code for the corelibs and saw that the current iteration is a pretty close direct API mapping of the Objective-C Foundation framework. If this stays the case, then I think I agree with you.

I was under the impression (my bad for not investigating beforehand) was that corelibs was an original library that provided the functionality of the Foundation framework but using all the power and idioms of Swift. I would have preferred that.

David.

···

On 03 Dec 2015, at 21:37, Gregory Casamento <greg.casamento@gmail.com> wrote:

David,

There wouldn't be any need to do it for every platform. There is one objective-C runtime GNUstep uses for every platform it runs on. So there is no need for it to be different.

Reimplementing everything in pure swift is silly because it would not allow re-use of all of the objective-c that is out there which is one of the advantages of swift in the first place.

GC

On Thu, Dec 3, 2015 at 3:32 PM, David Hart <david@hartbit.com <mailto:david@hartbit.com>> wrote:
I also agree with Adrian. I would much prefer to see efforts put towards implementing a pure Swift foundation API than supporting a Cocoa implementation and bridge on every platform Swift will run on.

On 03 Dec 2015, at 21:01, Gregory Casamento <greg.casamento@gmail.com <mailto:greg.casamento@gmail.com>> wrote:

Way ahead of you
On Thu, Dec 3, 2015 at 15:01 Maxthon Chan <xcvista@me.com <mailto:xcvista@me.com>> wrote:
Dear Swift developers:

Maybe you have never heard of it, but there have been several ongoing efforts, like GNUstep and Cocotron, at maintaining an open source Foundation reimplementation for alternative operating systems like Linux. It seemed to me that the current release of Swift did not put such efforts into consideration and brutally broke compatibility between Swift and Objective-C on Linux. I understand the fact that Apple is unwilling to release source code of Foundation, and this is usually where those alternative implementations comes into play.

Some of such projects, like GNUstep, are mature enough to allow existing AppKit applications written in Objective-C, like TextEdit and Chess, to be ported from OS X to Linux and Windows without changing too much, if any, code, taking all modern Objective-C features like ARC and object subscripting with stride, with a compatible version of LLVM compiler. Meanwhile, with the current version of Swift, even if the Swift code is written with calls to Objective-C runtime assuming the case on OS X, it is broken under Linux even with libobjc linked in.

I am here suggesting keeping the Objective-C bridge intact at least when built with a compatible version of libobjc (and GNUstep project have one already.) This will allow users of such alternative Foundation reimplementations to use their favourite Foundation distribution in place of the version provided by the Swift project, retaining the code compatibility already established between OS X and Linux by those Swift reimplementations.

In such an environment the alternative Foundation implementation will provide their own version of CoreFoundation and Foundation, implemented using C and Objective-C, as well as a libobjc that supports ARC. The Swift environment would be built without its own CoreFoundation and Foundation, but linking against the provided version instead, bridging calls just like OS X version of Swift does. This will also allow the new Swift platform to take full advantage of the AppKit came with the alternative Foundation, allow porting full OS X apps to Linux a lot easier. The above also applies for porting iOS apps, if the alternative Foundation implementation also comes with their own UIKit.

Max_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org <mailto:Gnustep-dev@gnu.org>
https://lists.gnu.org/mailman/listinfo/gnustep-dev

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Gregory Casamento
GNUstep Lead Developer / OLC, Principal Consultant
http://www.gnustep.org <http://www.gnustep.org/> - http://heronsperch.blogspot.com <http://heronsperch.blogspot.com/>
http://ind.ie/phoenix/


(ChanMaxthon) #14

David

Given the fact that there are two active Foundation reimplementations out there means your Swift-only reimplementation of Foundation is reinventing wheels, in an incompatible way. (Cocoatron can at least take a few libraries from GNUstep if compiled correctly, but not this)

The silliest way of doing this is just “endorse” someone* as the official Objective-C backend for Swift anywhere outside OS X and iOS and scratch this swift-corelibs-foundation entirely. Since both GNUstep and Cocotron runs under Linux, Windows and BSD instead of just Linux outside OS X and iOS, you get extra compatibility for free, from removing instead of adding code.

* preferably GNUstep in my own opinion, since they have better library coverage and they are the team that ships libobjc2 which fully supports ARC and every single modern Objective-C feature in a code-compatible way although not ABI-compatible, and the platform barrier rendered ABI compatibility pointless anyway

···

On Dec 4, 2015, at 04:37, Gregory Casamento <greg.casamento@gmail.com> wrote:

David,

There wouldn't be any need to do it for every platform. There is one objective-C runtime GNUstep uses for every platform it runs on. So there is no need for it to be different.

Reimplementing everything in pure swift is silly because it would not allow re-use of all of the objective-c that is out there which is one of the advantages of swift in the first place.

GC

On Thu, Dec 3, 2015 at 3:32 PM, David Hart <david@hartbit.com <mailto:david@hartbit.com>> wrote:
I also agree with Adrian. I would much prefer to see efforts put towards implementing a pure Swift foundation API than supporting a Cocoa implementation and bridge on every platform Swift will run on.

On 03 Dec 2015, at 21:01, Gregory Casamento <greg.casamento@gmail.com <mailto:greg.casamento@gmail.com>> wrote:

Way ahead of you
On Thu, Dec 3, 2015 at 15:01 Maxthon Chan <xcvista@me.com <mailto:xcvista@me.com>> wrote:
Dear Swift developers:

Maybe you have never heard of it, but there have been several ongoing efforts, like GNUstep and Cocotron, at maintaining an open source Foundation reimplementation for alternative operating systems like Linux. It seemed to me that the current release of Swift did not put such efforts into consideration and brutally broke compatibility between Swift and Objective-C on Linux. I understand the fact that Apple is unwilling to release source code of Foundation, and this is usually where those alternative implementations comes into play.

Some of such projects, like GNUstep, are mature enough to allow existing AppKit applications written in Objective-C, like TextEdit and Chess, to be ported from OS X to Linux and Windows without changing too much, if any, code, taking all modern Objective-C features like ARC and object subscripting with stride, with a compatible version of LLVM compiler. Meanwhile, with the current version of Swift, even if the Swift code is written with calls to Objective-C runtime assuming the case on OS X, it is broken under Linux even with libobjc linked in.

I am here suggesting keeping the Objective-C bridge intact at least when built with a compatible version of libobjc (and GNUstep project have one already.) This will allow users of such alternative Foundation reimplementations to use their favourite Foundation distribution in place of the version provided by the Swift project, retaining the code compatibility already established between OS X and Linux by those Swift reimplementations.

In such an environment the alternative Foundation implementation will provide their own version of CoreFoundation and Foundation, implemented using C and Objective-C, as well as a libobjc that supports ARC. The Swift environment would be built without its own CoreFoundation and Foundation, but linking against the provided version instead, bridging calls just like OS X version of Swift does. This will also allow the new Swift platform to take full advantage of the AppKit came with the alternative Foundation, allow porting full OS X apps to Linux a lot easier. The above also applies for porting iOS apps, if the alternative Foundation implementation also comes with their own UIKit.

Max_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org <mailto:Gnustep-dev@gnu.org>
https://lists.gnu.org/mailman/listinfo/gnustep-dev

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Gregory Casamento
GNUstep Lead Developer / OLC, Principal Consultant
http://www.gnustep.org <http://www.gnustep.org/> - http://heronsperch.blogspot.com <http://heronsperch.blogspot.com/>
http://ind.ie/phoenix/


(ChanMaxthon) #15

If it don’t, just notify GNUstep team and they will add it.

···

On Dec 4, 2015, at 04:52, David Hart <david@hartbit.com> wrote:

GC,

I just went to check the code for the corelibs and saw that the current iteration is a pretty close direct API mapping of the Objective-C Foundation framework. If this stays the case, then I think I agree with you.

I was under the impression (my bad for not investigating beforehand) was that corelibs was an original library that provided the functionality of the Foundation framework but using all the power and idioms of Swift. I would have preferred that.

David.

On 03 Dec 2015, at 21:37, Gregory Casamento <greg.casamento@gmail.com <mailto:greg.casamento@gmail.com>> wrote:

David,

There wouldn't be any need to do it for every platform. There is one objective-C runtime GNUstep uses for every platform it runs on. So there is no need for it to be different.

Reimplementing everything in pure swift is silly because it would not allow re-use of all of the objective-c that is out there which is one of the advantages of swift in the first place.

GC

On Thu, Dec 3, 2015 at 3:32 PM, David Hart <david@hartbit.com <mailto:david@hartbit.com>> wrote:
I also agree with Adrian. I would much prefer to see efforts put towards implementing a pure Swift foundation API than supporting a Cocoa implementation and bridge on every platform Swift will run on.

On 03 Dec 2015, at 21:01, Gregory Casamento <greg.casamento@gmail.com <mailto:greg.casamento@gmail.com>> wrote:

Way ahead of you
On Thu, Dec 3, 2015 at 15:01 Maxthon Chan <xcvista@me.com <mailto:xcvista@me.com>> wrote:
Dear Swift developers:

Maybe you have never heard of it, but there have been several ongoing efforts, like GNUstep and Cocotron, at maintaining an open source Foundation reimplementation for alternative operating systems like Linux. It seemed to me that the current release of Swift did not put such efforts into consideration and brutally broke compatibility between Swift and Objective-C on Linux. I understand the fact that Apple is unwilling to release source code of Foundation, and this is usually where those alternative implementations comes into play.

Some of such projects, like GNUstep, are mature enough to allow existing AppKit applications written in Objective-C, like TextEdit and Chess, to be ported from OS X to Linux and Windows without changing too much, if any, code, taking all modern Objective-C features like ARC and object subscripting with stride, with a compatible version of LLVM compiler. Meanwhile, with the current version of Swift, even if the Swift code is written with calls to Objective-C runtime assuming the case on OS X, it is broken under Linux even with libobjc linked in.

I am here suggesting keeping the Objective-C bridge intact at least when built with a compatible version of libobjc (and GNUstep project have one already.) This will allow users of such alternative Foundation reimplementations to use their favourite Foundation distribution in place of the version provided by the Swift project, retaining the code compatibility already established between OS X and Linux by those Swift reimplementations.

In such an environment the alternative Foundation implementation will provide their own version of CoreFoundation and Foundation, implemented using C and Objective-C, as well as a libobjc that supports ARC. The Swift environment would be built without its own CoreFoundation and Foundation, but linking against the provided version instead, bridging calls just like OS X version of Swift does. This will also allow the new Swift platform to take full advantage of the AppKit came with the alternative Foundation, allow porting full OS X apps to Linux a lot easier. The above also applies for porting iOS apps, if the alternative Foundation implementation also comes with their own UIKit.

Max_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org <mailto:Gnustep-dev@gnu.org>
https://lists.gnu.org/mailman/listinfo/gnustep-dev

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Gregory Casamento
GNUstep Lead Developer / OLC, Principal Consultant
http://www.gnustep.org <http://www.gnustep.org/> - http://heronsperch.blogspot.com <http://heronsperch.blogspot.com/>
http://ind.ie/phoenix/


(ChanMaxthon) #16

I am talking scaling projects back here. If you allow this bridging from the get-go you don't need anything other than the compiler, the standard libraries and half a runtime. Not even libdispatch or CoreFoundation is needed in this project since the Objective-C backend's authors are already maintaining it for you.

As a bonus point, if you can make the build system take Swift and Objective-C equally and not depend on Swift or Objective-C, the authors of the backend may even migrate their build system to the one here (since Cocotron does not have its own build system, and GNUstep's one is badly documented, clunky and hard to use)

···

Sent from my iPad

On Dec 4, 2015, at 04:32, David Hart <david@hartbit.com> wrote:

I also agree with Adrian. I would much prefer to see efforts put towards implementing a pure Swift foundation API than supporting a Cocoa implementation and bridge on every platform Swift will run on.

On 03 Dec 2015, at 21:01, Gregory Casamento <greg.casamento@gmail.com> wrote:

Way ahead of you

On Thu, Dec 3, 2015 at 15:01 Maxthon Chan <xcvista@me.com> wrote:
Dear Swift developers:

Maybe you have never heard of it, but there have been several ongoing efforts, like GNUstep and Cocotron, at maintaining an open source Foundation reimplementation for alternative operating systems like Linux. It seemed to me that the current release of Swift did not put such efforts into consideration and brutally broke compatibility between Swift and Objective-C on Linux. I understand the fact that Apple is unwilling to release source code of Foundation, and this is usually where those alternative implementations comes into play.

Some of such projects, like GNUstep, are mature enough to allow existing AppKit applications written in Objective-C, like TextEdit and Chess, to be ported from OS X to Linux and Windows without changing too much, if any, code, taking all modern Objective-C features like ARC and object subscripting with stride, with a compatible version of LLVM compiler. Meanwhile, with the current version of Swift, even if the Swift code is written with calls to Objective-C runtime assuming the case on OS X, it is broken under Linux even with libobjc linked in.

I am here suggesting keeping the Objective-C bridge intact at least when built with a compatible version of libobjc (and GNUstep project have one already.) This will allow users of such alternative Foundation reimplementations to use their favourite Foundation distribution in place of the version provided by the Swift project, retaining the code compatibility already established between OS X and Linux by those Swift reimplementations.

In such an environment the alternative Foundation implementation will provide their own version of CoreFoundation and Foundation, implemented using C and Objective-C, as well as a libobjc that supports ARC. The Swift environment would be built without its own CoreFoundation and Foundation, but linking against the provided version instead, bridging calls just like OS X version of Swift does. This will also allow the new Swift platform to take full advantage of the AppKit came with the alternative Foundation, allow porting full OS X apps to Linux a lot easier. The above also applies for porting iOS apps, if the alternative Foundation implementation also comes with their own UIKit.

Max_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(ChanMaxthon) #17

I am already seeing incompatibilities showing up on this list between this OC-less Swift and the OC-backed Swift that could have been avoided if this project supports OC bridging and some OC backend is provided.

···

Sent from my iPad

On Dec 4, 2015, at 04:52, David Hart <david@hartbit.com> wrote:

GC,

I just went to check the code for the corelibs and saw that the current iteration is a pretty close direct API mapping of the Objective-C Foundation framework. If this stays the case, then I think I agree with you.

I was under the impression (my bad for not investigating beforehand) was that corelibs was an original library that provided the functionality of the Foundation framework but using all the power and idioms of Swift. I would have preferred that.

David.

On 03 Dec 2015, at 21:37, Gregory Casamento <greg.casamento@gmail.com> wrote:

David,

There wouldn't be any need to do it for every platform. There is one objective-C runtime GNUstep uses for every platform it runs on. So there is no need for it to be different.

Reimplementing everything in pure swift is silly because it would not allow re-use of all of the objective-c that is out there which is one of the advantages of swift in the first place.

GC

On Thu, Dec 3, 2015 at 3:32 PM, David Hart <david@hartbit.com> wrote:
I also agree with Adrian. I would much prefer to see efforts put towards implementing a pure Swift foundation API than supporting a Cocoa implementation and bridge on every platform Swift will run on.

On 03 Dec 2015, at 21:01, Gregory Casamento <greg.casamento@gmail.com> wrote:

Way ahead of you

On Thu, Dec 3, 2015 at 15:01 Maxthon Chan <xcvista@me.com> wrote:
Dear Swift developers:

Maybe you have never heard of it, but there have been several ongoing efforts, like GNUstep and Cocotron, at maintaining an open source Foundation reimplementation for alternative operating systems like Linux. It seemed to me that the current release of Swift did not put such efforts into consideration and brutally broke compatibility between Swift and Objective-C on Linux. I understand the fact that Apple is unwilling to release source code of Foundation, and this is usually where those alternative implementations comes into play.

Some of such projects, like GNUstep, are mature enough to allow existing AppKit applications written in Objective-C, like TextEdit and Chess, to be ported from OS X to Linux and Windows without changing too much, if any, code, taking all modern Objective-C features like ARC and object subscripting with stride, with a compatible version of LLVM compiler. Meanwhile, with the current version of Swift, even if the Swift code is written with calls to Objective-C runtime assuming the case on OS X, it is broken under Linux even with libobjc linked in.

I am here suggesting keeping the Objective-C bridge intact at least when built with a compatible version of libobjc (and GNUstep project have one already.) This will allow users of such alternative Foundation reimplementations to use their favourite Foundation distribution in place of the version provided by the Swift project, retaining the code compatibility already established between OS X and Linux by those Swift reimplementations.

In such an environment the alternative Foundation implementation will provide their own version of CoreFoundation and Foundation, implemented using C and Objective-C, as well as a libobjc that supports ARC. The Swift environment would be built without its own CoreFoundation and Foundation, but linking against the provided version instead, bridging calls just like OS X version of Swift does. This will also allow the new Swift platform to take full advantage of the AppKit came with the alternative Foundation, allow porting full OS X apps to Linux a lot easier. The above also applies for porting iOS apps, if the alternative Foundation implementation also comes with their own UIKit.

Max_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Gregory Casamento
GNUstep Lead Developer / OLC, Principal Consultant
http://www.gnustep.org - http://heronsperch.blogspot.com
http://ind.ie/phoenix/


(David Hart) #18

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:

https://swift.org/documentation/api-design-guidelines.html

Hope this helps,
- Tony

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?

Quiz: what's the result of NSURL(string: "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
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

(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.

Thanks,
- Tony

_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev


(ChanMaxthon) #19

Swift without Objective-C support will miss out a few important pieces that is crucial to the success of Objective-C outside OS X:

1) AppKit and UIKit. Both GNUstep and Cocotron have their version of AppKit and GNUstep even have a version of UIKit. Missing this means there is no way writing portable Swift app that have any form of GUI.
2) WebObjects. I know that Apple deprecated WebObjects for Objective-C long ago, but its clone in GNUstep is still used and maintained. Missing out this means that you cannot easily write Web applications using Swift on Linux without going back to CGI or FastCGI - kind of defeats its purpose isn’t it?
3) Code compatibility. One of the best features of both Cocotron and GNUstep is that it allows OS X app to be ported to other platforms without changing its code. This Swift apparently won’t do this.

Max

···

On Dec 4, 2015, at 06:13, Chris Lattner <clattner@apple.com> wrote:

On Dec 3, 2015, at 12:01 PM, Maxthon Chan <xcvista@me.com> wrote:

Dear Swift developers:

Maybe you have never heard of it, but there have been several ongoing efforts, like GNUstep and Cocotron, at maintaining an open source Foundation reimplementation for alternative operating systems like Linux. It seemed to me that the current release of Swift did not put such efforts into consideration and brutally broke compatibility between Swift and Objective-C on Linux. I understand the fact that Apple is unwilling to release source code of Foundation, and this is usually where those alternative implementations comes into play.

Hi Maxthon,

Thanks for your interest, we’re definitely aware of GNUstep and Cocotron.

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.

We’re aware that this means that it will take longer for the Swift Foundation to be fully operational and useful, but that is a tradeoff we’re willing to make. You are of course welcome to make Swift work with GNUstep or Cocotron if you’re interested in doing that, but that seems outside the charter of the work on Swift Foundation.

-Chris

Some of such projects, like GNUstep, are mature enough to allow existing AppKit applications written in Objective-C, like TextEdit and Chess, to be ported from OS X to Linux and Windows without changing too much, if any, code, taking all modern Objective-C features like ARC and object subscripting with stride, with a compatible version of LLVM compiler. Meanwhile, with the current version of Swift, even if the Swift code is written with calls to Objective-C runtime assuming the case on OS X, it is broken under Linux even with libobjc linked in.

I am here suggesting keeping the Objective-C bridge intact at least when built with a compatible version of libobjc (and GNUstep project have one already.) This will allow users of such alternative Foundation reimplementations to use their favourite Foundation distribution in place of the version provided by the Swift project, retaining the code compatibility already established between OS X and Linux by those Swift reimplementations.

In such an environment the alternative Foundation implementation will provide their own version of CoreFoundation and Foundation, implemented using C and Objective-C, as well as a libobjc that supports ARC. The Swift environment would be built without its own CoreFoundation and Foundation, but linking against the provided version instead, bridging calls just like OS X version of Swift does. This will also allow the new Swift platform to take full advantage of the AppKit came with the alternative Foundation, allow porting full OS X apps to Linux a lot easier. The above also applies for porting iOS apps, if the alternative Foundation implementation also comes with their own UIKit.

Max_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev


(ChanMaxthon) #20

Both GNUstep and Cocotron have already achieved this “OS independence and portability” better than you think, on a wider variety of platforms - Linux as well as Windows and FreeBSD. So if you open up the Objective-C compatibility layer and leave the Foundation to them you may have even better OS independence.

···

On Dec 4, 2015, at 06:46, Tony Parker <anthony.parker@apple.com> wrote:

On Dec 3, 2015, at 2:37 PM, Jacob Bandes-Storch <jtbandes@gmail.com <mailto:jtbandes@gmail.com>> wrote:

Thanks, Tony.

On Thu, Dec 3, 2015 at 2:33 PM, Tony Parker <anthony.parker@apple.com <mailto:anthony.parker@apple.com>> wrote:
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.

Agreed. I look forward to it :slight_smile: I'm just concerned that users will expect behavior to exactly match their equivalent Obj-C code. If these bugs are fixed / APIs are refined in corelibs-foundation, that expectation might be broken.

Indeed, a very good point and something we are actively thinking about.

An important goal of our project is to provide a layer of OS independence and portability. There may be times when we have a bug in the Obj-C implementation that we therefore decide to reflect in the Swift implementation as well, because the inconsistency would otherwise be a problem. Hopefully this doesn’t happen too often. I’d rather fix the bug in the Obj-C implementation as well, but there are always going to be tradeoffs to make.

We have lots of experience making changes to Foundation underneath apps and keeping things compatible. I think we’ll certainly be using some of that as we move forward with the Swift Foundation implementation as well. For example, we may choose to deprecate a confusing (or wrong) API and replace it with something better. We’d like the bar for changing API to be very high, though, so that we can provide as much stability to clients as possible.

Thanks,
- Tony

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.

Will do!

_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev