IMHO on Linux NSKeyedArchiver should always use mangled names. If we want cross-platform archives, we should set up standard substitutions, but given that Swift classes exposed to Objective-C are archived with their full names it doesn't make sense to use "half the name" in the archive.
Jordan > On Dec 19, 2015, at 13:23 , Philippe Hausler 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. > > 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 _______________________________________________ swift-corelibs-dev mailing list swift-corelibs-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
