[swift-corelibs-dev] NSCoding methods

Jordan Rose jordan_rose at apple.com
Mon Dec 21 12:50:59 CST 2015


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



More information about the swift-corelibs-dev mailing list