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

[Maxthon Chan]

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



smime.p7s
Description: S/MIME cryptographic signature
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

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

[Maxthon Chan]

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  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 > <mailto:xcvi...@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 >> <mailto:alex.blew...@gmail.com>> wrote:
>>> 
>>> A more interesting question would be: is Swift designed to ultimately 
>>> replace Objective-C? If so, baking in compatibility from the outset of the 
>>> open source version would probably be going in the wrong direction.
>>> 
>>> Alex
>>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolut...@swift.org <mailto:swift-evolut...@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 



smime.p7s
Description: S/MIME cryptographic signature
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

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

[Maxthon Chan]

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  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 > > 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 > > 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 >> > 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  > 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 > > wrote:
>> 
>> Hi Jacob,
>> 
>>> On Dec 3, 2015, at 2:23 PM, Jacob Bandes-Storch >> > wrote:
>>> 
>>> On Thu, Dec 3, 2015 at 2:13 PM, Chris Lattner >> > wrote:
>>> 
>>> As others have surmised, the goal for the Swift Foundation project is 
>