> On 27 Dec 2015, at 3:45 AM, Philippe Hausler <phaus...@apple.com> wrote: > > Totally reasonable since that is a limitation that will cause subclassers to > not be able to implement that even outside of Foundation. > > What would help most for unit testing what you have so far? > > I have a few init?(coder:) implementations that should match the > implementations on darwin; primarily I was focused on getting the plist types > done first and then moving onto the other classes.
I’ve done the plist classes and a few others such as NSURL, NSLocale, NSUUID. I’m going to look at the rest today, other remaining todos are: * encodeValueOfObjCType() * reviewing fatal vs non-fatal error cases * testing reading/writing from a stream (vs memory), seem to be some issues with this * unit tests * incremental decoding (probably will not get to this) Also I’m only looking at NSKeyedArchiver – do we need to support NSArchiver? Finally, I filed a few bugs (with patches) for things I bumped into along the way: * SR-378: Uninitialised memory in NSDictionary initialiser * SR-379: CFDictionaryGetKeysAndValues() bridges in wrong order * SR-380: Occasional crashes in NSString.hash.getter * SR-381: Request for API to return mangled nominal type name * SR-386: NSLog() API — Luke _______________________________________________ swift-corelibs-dev mailing list swift-corelibs-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
