[swift-corelibs-dev] NSCoding methods

[Luke Howard]

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 at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev