[swift-corelibs-dev] NSCoding methods
phausler at apple.com
Sat Dec 12 14:47:00 CST 2015
These were not implemented yet since we did not have a way to actually verify archives. Part of the goal is to have archives be serializable on Darwin platforms and de-serializable on linux (and visa-versa). That way someone could presumably archive objects on an iPhone and send the archive over the wire to a linux machine and that machine would be able to de-serialize it and yield the appropriate structure. This means that we need to make certain while implementing these that they mimic the same coder keys and structural serialization order (when not initing with a keyed archiver). NSCoder itself has a start of an implementation but NSKeyedArchiver has a limitation in that we cannot yet build construction of objects dynamically from their class name. 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.
It might also be a good start to build a verification NSCoder subclass to verify the order and keys/values for any abstract class. That way we can test and verify the coding/decoding on all platforms.
> On Dec 12, 2015, at 11:58 AM, Daniel Strokis via swift-corelibs-dev <swift-corelibs-dev at swift.org> wrote:
> Hi All,
> I’ve noticed that for many classes in Foundation, encodeWithCoder and init?(coder aDecoder: NSCoder) call NSUnimplemented. Are these methods that just haven’t been implemented yet, or are we not interested in implementing these moving forward? Apologies if this has already been discussed before and I’m just out of the loop.
> Daniel Strokis
> swift-corelibs-dev mailing list
> swift-corelibs-dev at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-corelibs-dev