It's not too hard to figure out (and there are a couple of other ObjC implementations) but if Apple have any specs for the archive format, I would be keen to take a look.
Also regarding interoperability - perhaps it might be reasonable, for non-Foundation classes that have non-namespaced names (on non-ObjC platforms) for the caller to configure the NSKeyedArchiver with explicit class mappings? -- Luke Sent from my iPhone > On 21 Dec 2015, at 00:02, Luke Howard via swift-corelibs-dev > <swift-corelibs-dev@swift.org> wrote: > > >> Somewhat; the mangled symbols are technically searchable by dlsym but that >> seems like a hack. Perhaps one of the stdlib/compiler team might be able to >> speak more on this than myself and they may have suggestions for a better >> way. Foundation is at a special spot in which we can sometimes get special >> runtime considerations for these types of things. > > It’d arguably be more of a hack to add a global manifest of classes if the > dynamic linker already has one ;-) Here’s a toy implementation of > swift_classFromString(): > > https://github.com/lhoward/SwiftRuntimeTest > > Disclaimer: I know very little about Swift nor its implementation beyond a > bit of poking around. > >> For example NSUUID is defined by it’s module name Foundation.NSUUID; in that >> a program could have it’s own NSUUID that is totally different (naming it >> the same thing would be confusing to read and potentially viewed as bad form >> but it can be done…). That would result in MyApplication.NSUUID to define >> the symbolic name of the item. From the perspective of NSKeyedArchiver it >> will encode things as NSUUID (without the namespace) in that in the realm of >> objc there can be only one. > > What if you (re-)added the ability to annotate Swift classes with their > Objective-C name on non-Apple platforms? I don’t know what the runtime costs > of doing this are but it seems like it’s either this, or only allow > non-namespaced names for Foundation objects. > > — 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
