To clarify the goals: I think it is reasonable for us to have a goal to be able to encode/decode archives from foreign targets; e.g. linux encodes an archive and mac os x decodes or iOS encodes and linux decodes. This will allow for server architecture to transmit binary archives across the wire. This will mean that we will want to have the encoded class names from the application scope to be encoded as the non mangled name but with the namespace. However this presents a problem; Foundation will have a namespace which will need to be inferred both for encoding and decoding. Thankfully there may be a reasonable way to approach this;
public class func classNameForClass(cls: AnyClass) -> String? public class func setClassName(codedName: String?, forClass cls: AnyClass) These methods can be used to allow for translation of classes by registering the appropriate classes for a “shortened” name that drops the Foundation/SwiftFoundation namespace prefix during encoding. > On Dec 22, 2015, at 2:45 AM, Luke Howard via swift-corelibs-dev > <swift-corelibs-dev@swift.org> wrote: > > >> On 22 Dec 2015, at 5:50 AM, Jordan Rose <jordan_r...@apple.com> wrote: >> >> IMHO on Linux NSKeyedArchiver should always use mangled names. If we want >> cross-platform archives, we should set up standard substitutions, but given >> that Swift classes exposed to Objective-C are archived with their full names >> it doesn't make sense to use "half the name" in the archive. > > You mean namespaced but unmangled yes? If so I agree. > > BTW I found a couple of small CF nits: > > * in CFDictionaryGetKeysAndValues(), keybuf and valuebuf are transposed in > the call to CF_SWIFT_FUNCDISPATCHV(NSDictionary.getObjects()) > > * _CFSwiftDictionaryGetKeysAndValues() does not handle keybuf or valbuf being > NULL (either of which are valid when calling CFDictionaryGetKeysAndValues()) > This is a bit un-related to NSCoding and the transposition is probably a mistake if it is inverted (the CF method should be reversed from the NS method to mimic the objc counterpart) > — Luke > _______________________________________________ > swift-corelibs-dev mailing list > swift-corelibs-dev@swift.org > https://lists.swift.org/mailman/listinfo/swift-corelibs-dev _______________________________________________ swift-corelibs-dev mailing list swift-corelibs-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
