> 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
