> On Dec 30, 2015, at 6:57 PM, Luke Howard <lu...@padl.com> wrote: > > >> On 31 Dec 2015, at 11:25 AM, Luke Howard via swift-dev <swift-dev@swift.org> >> wrote: >> >>> I really want to merge in the rest of the coders; so lets go ahead and omit >>> the mangling stuff and leave it just as the Foundation classes . That will >>> be a huge win in my book, it gives us something that is testable and >>> functional enough to do some pretty impressive demonstrations of archiving. >> >> OK, the version I’ve pushed now removes the code that was poking into >> runtime structures but still uses dlopen()/the metadata accessor for >> NSClassFromString(). Tests verify on OS X and Linux (with compiler fix). >> >> If you want to change this further to use a static mapping table, go for it, >> but I’d rather focus my time on getting the appropriate API into stdlib. > > As a compromise how about a: > > * swift_getTypeByName() API that only takes demangled names > * NSClassFromString()/NSStringFromClass() remain internal and hard fail with > nested classes/generics > * We decide what to do about nested class interop later (is changing the > Darwin behaviour something that would even be on the table?) > > — Luke
I think those are all pretty reasonable. The pipeline for changes is bi-directional; however it will have to get reviewed by the component owner and undergo our process to change API behavior internally. I am fairly certain that this is an edge case that hasn’t even been thought of and I would think that the rest of the Foundation team will be very apt to nail this down so we don’t have to worry about backwards compatibility problems that using the mangled name might incur in the future. _______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
