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.
The tricksy spot would be cases where you would need to fetch a class without the module name. 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. The tl;dr is that there is no manifest of classes or table of names stored in the binaries; just symbols. > On Dec 18, 2015, at 10:57 PM, Luke Howard <lu...@padl.com> wrote: > > >> Specifically there is no NSClassFromString yet. I would say if you are >> looking for a place to start, perhaps coming up with a good strategy for >> accomplishing that in a uniform manner (for both Foundation classes as well >> as user classes) would be a good step in the right direction to getting this >> started. > > Does Swift have enough runtime metadata to do this for native Swift classes? > > -- Luke _______________________________________________ swift-corelibs-dev mailing list swift-corelibs-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
