[swift-corelibs-dev] NSCoding methods

[Luke Howard]

> On 24 Dec 2015, at 10:12 AM, Philippe Hausler <phausler at apple.com> wrote:
> 
> NSCoding will have to use something to transform from strings to classes, and that satisfy the two cases (or more) that we have already shown, currently there is no thing that does that in either form; either mangled or non mangled. Basically we need something to implement NSClassFromString with. Which we have clearly shown that dlsym does not fully meet the needs since there are cases that will emit as “module.classname” and others that emit as the mangled name. The simple case is probably going to be the a very common usage pattern for consumers (and of previously built applications). The inner class should definitely be handled in addition to this case.

* If the mangled name is present in the archive, you can re-mangle it to get the metadata accessor
* If it’s a one-level unmangled name representing a class, it can be mangled
* If it’s a zero-level unmangled name, then it seems reasonable for a first implementation to assume it’s a SwiftFoundation class (or that the caller has set an explicit mapping)

Noted that dlsym() will only work with public symbols.

> Are there any methods that can fetch the name (either the symbolic or the readable) given a AnyClass in the runtime to get work started here? I think it is definitely sensible as a start to restrict this just to descendants of the class NSObject. I would presume that since the Metadata is potentially volatile contents we should use something along the lines of swift_getTypeName etc?


I have been using _typeName() but it always demangles – for interop with existing archives we need to match the behaviour of libobjc's class_getName() (equivalent to NSStringFromClass), which appears to demangle one-level classes.

— Luke
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-corelibs-dev/attachments/20151224/ce91a033/attachment.html>