Re: [swift-corelibs-dev] [swift-corelibs-libdispatch] Port transform and use libbsd (#13)
On Dec 14, 2015, at 8:12 PM, Pierre Habouzit via swift-corelibs-dev wrote: > > Technically, until someone ports libdispatch to GNU/Hurd,it’s okay to use #if > __APPLE__ to hide anything mach related. I think it would be better not to conflate __APPLE__ and HAVE_MACH. I don't expect a libdispatch port to OSF/1 any time soon, but libdispatch is already used in Jordan Hubbard's "NextBSD" effort, and that actually does provide Mach APIs without being an Apple platform. -- Chris ___ swift-corelibs-dev mailing list swift-corelibs-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
Re: [swift-corelibs-dev] NSCoding methods
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 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
