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

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

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

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

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

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 so

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

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 s

Re: [swift-corelibs-dev] Third party license compatible libraries for JSON

Sorry, forgot to include the link: http://zserge.com/jsmn.html > On 4 Dec 2015, at 13:33, swizzlr wrote: > > I would like to begin work on implementing NSJSONSerialization. I believe > that to get this up and running quickly, it would be prudent to vendor jsmn > () within Foundation so we can

[swift-corelibs-dev] Third party license compatible libraries for JSON

I would like to begin work on implementing NSJSONSerialization. I believe that to get this up and running quickly, it would be prudent to vendor jsmn () within Foundation so we can quickly provide an implementation which will be crucial to web server support, instead of writing our own tokenizer

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

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

Re: [swift-corelibs-dev] [xctest] Who tests the tests?

One possible direction to consider which would be more consistent with our goals this year for API-compatibility would be to look into implementing XCTestObserver. Mike > On Dec 3, 2015, at 8:03 PM, Tony Parker wrote: > > Hi Brian, > >> On Dec 3, 2015, at 3:45 PM, Brian Gesiak >

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

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 s

[swift-corelibs-dev] Rules on adding dependencies

I was wondering what the official position on introducing dependencies currently is. I would love to contribute an implementation of NSJSONSerialization. I already have written a wrapper that uses yajl to take a CFDictionaryRef or CFArrayRef and encodes them into CFDataRef or CFStringRef JSON v

Re: [swift-corelibs-dev] Rules on adding dependencies

Hi Tom, I believe it’s important for us to keep our dependencies to an absolute minimum for the core libraries, since they will be distributed very widely. I would prefer to have our own implementation of the JSON parser in Foundation rather than use one from another project. The one from Darw

Re: [swift-corelibs-dev] [xctest] Who tests the tests?

Oops. It was pointed out to me that XCTestObserver is deprecated. I get it confused sometimes with its replacement.. What we’d presumably want to pursue adding the the corelibs XCTest is the API from XCTestObservation.h (and associated stuff). Your same questions about the bundle stuff will st

Re: [swift-corelibs-dev] Rules on adding dependencies

Hey Tony, That sounds like a good objective overall, thanks for clarifying. I think you guys should write that someplace in the documentation on github (if it hasn’t been already) Thomas Leavy | Wickr Inc. VP Mobile Applications, Architecture | Newark, NJ > On Dec 4, 2015, at 2:39 PM, anthony

Re: [swift-corelibs-dev] Rules on adding dependencies

Good idea, I filed a bug for that here. https://bugs.swift.org/browse/SR-59 - Tony > On Dec 4, 2015, at 12:49 PM, Tom Leavy wrote: > > Hey Tony, > > That sounds like a good objective overall, thanks for clarifying. I think you > guys should write that so

Re: [swift-corelibs-dev] Will the Portability Stack include KVC/KVO support?

Hi Benoit, KVO and KVC rely heavily on the presence of the Objective-C runtime (for example, sometimes creating new subclasses for objects out of thin air). We’re not sure yet how or if we want to implement that functionality. In the meantime, filing a bug at bugs.swift.org would be a great wa

Re: [swift-corelibs-dev] Rules on adding dependencies

Thanks! Is there a list of current dependencies someplace? I understand you use a specific version of ICU as part of CoreFoundation. Thomas Leavy | Wickr Inc. VP Mobile Applications, Architecture | Newark, NJ On Dec 4, 2015, at 3:52 PM, anthony.par...@apple.com

Re: [swift-corelibs-dev] swift-corelibs-dev Digest, Vol 1, Issue 18

osure under applicable law. If you have > received this message in error please immediately notify the sender by return > e-mail and delete this e-mail message from your computer, mobile devices and > any cloud storage backup systems as well as destroy any printed copy you > might

[swift-corelibs-dev] New contributions document

Hi everyone, Thank you so much for your interest in the Core Libraries over the first 2 days! Your response to the release has been overwhelming, and we’re really looking forward to working with you on this project going forward. I quickly realized that we needed to clarify some of the process