Re: [swift-corelibs-dev] NSCoding methods

I’m planning to use this for now: https://github.com/lhoward/swift-corelibs-foundation/commit/177e7d9f945db58217edec70d90d5cb53cba0245 Noted that it won’t work for non-public symbols, but at l

Re: [swift-corelibs-dev] NSCoding methods

My plan was just to map any flat unmangled names to SwiftFoundation classes without the boilerplate explicit mappings, but happy to change approaches. That's what the code in the branch I posted yesterday does, but I need to fix it to encode the mangled name for non-one level class types - was p

Re: [swift-corelibs-dev] NSCoding methods

My plan was just to map any flat unmangled names to SwiftFoundation classes without the boilerplate explicit mappings, but happy to change approaches. That's what the code in the branch I posted yesterday does, but I need to fix it to encode the mangled name for non-one level class types - was p

Re: [swift-corelibs-dev] NSCoding methods

So one thing we can do in the interim until there is a sanctioned way for us to convert strings to classes and classes to strings is we can register the classes globally for transformation so that the Foundation or SwiftFoundation module name won’t be an issue. By doing this early on in the ini

Re: [swift-corelibs-dev] NSCoding methods

> On 24 Dec 2015, at 10:12 AM, Philippe Hausler wrote: > > NSCoding will have to use something to transform from strings to classes, and > that satisfy the two cases (or more) that we have already shown, currently > there is no thing that does that in either form; either mangled or non > mang

Re: [swift-corelibs-dev] NSCoding methods

"We need to get ahold of a class given a name" is definitely a requirement to do NSCoding right. I'm not at all convinced dlsym is a valid long-term answer for that, though. If you have an 'internal' class, it doesn't (currently) have a public symbol that you can use dlsym for. This sort of goe

Re: [swift-corelibs-dev] NSCoding methods

> On 24 Dec 2015, at 9:37 AM, Jordan Rose wrote: > > No, we cannot encode things "non-mangled but with the namespace". For any > type other than top-level non-generic class types, using a non-mangled name > is not unique. The only correct answer for arbitrary classes is to use > mangled names

Re: [swift-corelibs-dev] NSCoding methods

NSCoding will have to use something to transform from strings to classes, and that satisfy the two cases (or more) that we have already shown, currently there is no thing that does that in either form; either mangled or non mangled. Basically we need something to implement NSClassFromString with

Re: [swift-corelibs-dev] NSCoding methods

Here's another example on OS X: import Foundation class Outer { class Inner : NSObject, NSCoding { let uuid: Foundation.NSUUID required init?(coder aDecoder: NSCoder) { uuid = aDecoder.decodeObjectForKey("my.uuid") as! Foundation.NSUUID } override i

Re: [swift-corelibs-dev] NSCoding methods

The archiving format encodes the names of the classes in the archive itself. Here are a few code examples and a quasi readable output from them: let uuid = NSUUID() let data = NSKeyedArchiver.archivedDataWithRootObject(uuid) let archive = try! NSPropertyListSerialization.propertyListWithData(data

Re: [swift-corelibs-dev] NSCoding methods

No, we cannot encode things "non-mangled but with the namespace". For any type other than top-level non-generic class types, using a non-mangled name is not unique. The only correct answer for arbitrary classes is to use mangled names, or something that maps one-to-one with mangled names. Now,

Re: [swift-corelibs-dev] Upcoming holiday schedule

Thanks for the work on this, I will take a look at them later today. Part of the hold up on some of the pull requests are that we still have a few compiler crashers lurking around and there are a few pr’s that need a bit more work. I am leaving XCTest to that team unless it is a critical issue a

Re: [swift-corelibs-dev] Upcoming holiday schedule

Hi guys - unsure if it's helpful at your end but I rebased (almost) all of the open PR's as of this morning on the current HEAD of master (5435ec4), removed any of the wrong way merges, cleaned up the conflicts and pushed them to my fork. They're all available here: https://github.com/tomj/swift-c