[swift-corelibs-dev] NSCoding methods

[Luke Howard]

> 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