Query on NSKeyedArchiver

Sai_Kanduri · 2016-10-26T11:07:23.000Z

Hi Tony,

From your comments on Pull Request #574 I understand that we cannot archive/un-archive non-NS objects using NsKeyedArchiver & NSKeyedUnarchiver.I s my understanding correct ..? Does this means that archiving and un-archiving of swift types is not supported on Linux ?

-Sai Hema

Tony_Parker · 2016-10-26T17:11:41.000Z

Hi Sai,

We do have basic support for keyed archiving and unarchiving in swift-corelibs-foundation on Linux. The limitation is that the NSCoding protocol cannot be applied to Swift struct types, only class types. On Darwin, the class also must be a subclass of NSObject. This last limitation may not exist on Linux, but you should be aware that if you encode a non-NSObject subclass on Linux then you would not be able to decode it on Darwin.

- Tony

···

On Oct 26, 2016, at 4:07 AM, Sai Kanduri via swift-corelibs-dev <swift-corelibs-dev@swift.org> wrote:

Hi Tony,

From your comments on Pull Request #574 I understand that we cannot archive/un-archive non-NS objects using NsKeyedArchiver & NSKeyedUnarchiver.I s my understanding correct ..? Does this means that archiving and un-archiving of swift types is not supported on Linux ?

-Sai Hema

_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Max_Desiatov · 2016-10-26T17:14:58.000Z

Hi Tony,

This is very interesting caveat. Is there a plan to get this documented anywhere? I haven't seen any documentation for Swift Foundation published publicly anywhere akin to how it's done for other APIs at https://developer.apple.com/reference/\.

With best regards, Max.

···

On 26 Oct 2016, at 18:11, Tony Parker via swift-corelibs-dev <swift-corelibs-dev@swift.org> wrote:

Hi Sai,

We do have basic support for keyed archiving and unarchiving in swift-corelibs-foundation on Linux. The limitation is that the NSCoding protocol cannot be applied to Swift struct types, only class types. On Darwin, the class also must be a subclass of NSObject. This last limitation may not exist on Linux, but you should be aware that if you encode a non-NSObject subclass on Linux then you would not be able to decode it on Darwin.

- Tony

On Oct 26, 2016, at 4:07 AM, Sai Kanduri via swift-corelibs-dev <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote:

Hi Tony,

From your comments on Pull Request #574 I understand that we cannot archive/un-archive non-NS objects using NsKeyedArchiver & NSKeyedUnarchiver.I s my understanding correct ..? Does this means that archiving and un-archiving of swift types is not supported on Linux ?

-Sai Hema

_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Tony_Parker · 2016-10-26T17:22:49.000Z

Hi Tony,

This is very interesting caveat. Is there a plan to get this documented anywhere? I haven't seen any documentation for Swift Foundation published publicly anywhere akin to how it's done for other APIs at https://developer.apple.com/reference/\.

With best regards, Max.

With respect to the NSObject requirement: It’s really more of a known issue than a permanent limitation.

To over summarize the situation: NSKeyedArchiver (the Objective-C one) puts a private category on NSObject and assumes all objects respond to those messages after that.

We don’t really have documentation for swift-corelibs-foundation beyond what we can put in our own headerdoc format there. That would be something I would really appreciate help on if anyone is interested in contributing.

- Tony

···

On Oct 26, 2016, at 10:14 AM, Max Desiatov <max.desiatov@gmail.com> wrote:

On 26 Oct 2016, at 18:11, Tony Parker via swift-corelibs-dev <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote:

Hi Sai,

We do have basic support for keyed archiving and unarchiving in swift-corelibs-foundation on Linux. The limitation is that the NSCoding protocol cannot be applied to Swift struct types, only class types. On Darwin, the class also must be a subclass of NSObject. This last limitation may not exist on Linux, but you should be aware that if you encode a non-NSObject subclass on Linux then you would not be able to decode it on Darwin.

- Tony

On Oct 26, 2016, at 4:07 AM, Sai Kanduri via swift-corelibs-dev <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote:

Hi Tony,

From your comments on Pull Request #574 I understand that we cannot archive/un-archive non-NS objects using NsKeyedArchiver & NSKeyedUnarchiver.I s my understanding correct ..? Does this means that archiving and un-archiving of swift types is not supported on Linux ?

-Sai Hema

_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

lukeh · 2016-10-27T09:56:13.000Z

BTW is anything blocking integrating SR-2416?

github.com/apple/swift-corelibs-foundation

[SR-2416] allow non-NSObject types to be archived

apple:master ← lhoward:SR-2416

opened 04:18AM - 19 Aug 16 UTC

lhoward

+79 -31

This patch fixes a number of issues that were preventing non-NSObject types from… being archived, even though the new method signatures imply that they can be (by taking Any). - fix regression introduced aa504dcd where non-hashable objects could not be encoded - fix bug where non-NSObjects would be replaced with nil, causing a crash - remove explicit check that the encoded object is a NSObject - possibly should be a separate patch: transparently bridge value types to the corresponding reference type before encoding - tests for all over the above

That allows value types to be archived too if they support _ObjectBridgeable (they’ll come back as reference types though).

···

On 27 Oct 2016, at 4:22 AM, Tony Parker via swift-corelibs-dev <swift-corelibs-dev@swift.org> wrote:

On Oct 26, 2016, at 10:14 AM, Max Desiatov <max.desiatov@gmail.com <mailto:max.desiatov@gmail.com>> wrote:

Hi Tony,

This is very interesting caveat. Is there a plan to get this documented anywhere? I haven't seen any documentation for Swift Foundation published publicly anywhere akin to how it's done for other APIs at https://developer.apple.com/reference/\.

With best regards, Max.

With respect to the NSObject requirement: It’s really more of a known issue than a permanent limitation.

To over summarize the situation: NSKeyedArchiver (the Objective-C one) puts a private category on NSObject and assumes all objects respond to those messages after that.

We don’t really have documentation for swift-corelibs-foundation beyond what we can put in our own headerdoc format there. That would be something I would really appreciate help on if anyone is interested in contributing.

- Tony

On 26 Oct 2016, at 18:11, Tony Parker via swift-corelibs-dev <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote:

Hi Sai,

We do have basic support for keyed archiving and unarchiving in swift-corelibs-foundation on Linux. The limitation is that the NSCoding protocol cannot be applied to Swift struct types, only class types. On Darwin, the class also must be a subclass of NSObject. This last limitation may not exist on Linux, but you should be aware that if you encode a non-NSObject subclass on Linux then you would not be able to decode it on Darwin.

- Tony

On Oct 26, 2016, at 4:07 AM, Sai Kanduri via swift-corelibs-dev <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote:

Hi Tony,

From your comments on Pull Request #574 I understand that we cannot archive/un-archive non-NS objects using NsKeyedArchiver & NSKeyedUnarchiver.I s my understanding correct ..? Does this means that archiving and un-archiving of swift types is not supported on Linux ?

-Sai Hema

_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Luke Howard
web <http://lukehoward.com/> / facebook <Facebook; / soundcloud <https://soundcloud.com/lukehoward/> / spotify <https://open.spotify.com/artist/3duTXsC49HoPt4f4EySDKf>

Tony_Parker · 2016-10-27T16:06:09.000Z

Sorry, this fell off my radar. I’ll test and merge again.

- Tony

···

On Oct 27, 2016, at 2:56 AM, Luke Howard <lukeh@padl.com> wrote:

BTW is anything blocking integrating SR-2416?

[SR-2416] allow non-NSObject types to be archived by lhoward · Pull Request #574 · apple/swift-corelibs-foundation · GitHub

That allows value types to be archived too if they support _ObjectBridgeable (they’ll come back as reference types though).

On 27 Oct 2016, at 4:22 AM, Tony Parker via swift-corelibs-dev <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote:

On Oct 26, 2016, at 10:14 AM, Max Desiatov <max.desiatov@gmail.com <mailto:max.desiatov@gmail.com>> wrote:

Hi Tony,

This is very interesting caveat. Is there a plan to get this documented anywhere? I haven't seen any documentation for Swift Foundation published publicly anywhere akin to how it's done for other APIs at https://developer.apple.com/reference/\.

With best regards, Max.

With respect to the NSObject requirement: It’s really more of a known issue than a permanent limitation.

To over summarize the situation: NSKeyedArchiver (the Objective-C one) puts a private category on NSObject and assumes all objects respond to those messages after that.

We don’t really have documentation for swift-corelibs-foundation beyond what we can put in our own headerdoc format there. That would be something I would really appreciate help on if anyone is interested in contributing.

- Tony

On 26 Oct 2016, at 18:11, Tony Parker via swift-corelibs-dev <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote:

Hi Sai,

We do have basic support for keyed archiving and unarchiving in swift-corelibs-foundation on Linux. The limitation is that the NSCoding protocol cannot be applied to Swift struct types, only class types. On Darwin, the class also must be a subclass of NSObject. This last limitation may not exist on Linux, but you should be aware that if you encode a non-NSObject subclass on Linux then you would not be able to decode it on Darwin.

- Tony

On Oct 26, 2016, at 4:07 AM, Sai Kanduri via swift-corelibs-dev <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote:

Hi Tony,

From your comments on Pull Request #574 I understand that we cannot archive/un-archive non-NS objects using NsKeyedArchiver & NSKeyedUnarchiver.I s my understanding correct ..? Does this means that archiving and un-archiving of swift types is not supported on Linux ?

-Sai Hema

_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Luke Howard
web <http://lukehoward.com/> / facebook <Facebook; / soundcloud <https://soundcloud.com/lukehoward/> / spotify <https://open.spotify.com/artist/3duTXsC49HoPt4f4EySDKf>

lukeh · 2016-10-28T00:58:04.000Z

Thanks, SR closed.

···

On 28 Oct 2016, at 3:06 AM, Tony Parker <anthony.parker@apple.com> wrote:

Sorry, this fell off my radar. I’ll test and merge again.

- Tony

On Oct 27, 2016, at 2:56 AM, Luke Howard <lukeh@padl.com <mailto:lukeh@padl.com>> wrote:

BTW is anything blocking integrating SR-2416?

[SR-2416] allow non-NSObject types to be archived by lhoward · Pull Request #574 · apple/swift-corelibs-foundation · GitHub

That allows value types to be archived too if they support _ObjectBridgeable (they’ll come back as reference types though).

On 27 Oct 2016, at 4:22 AM, Tony Parker via swift-corelibs-dev <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote:

On Oct 26, 2016, at 10:14 AM, Max Desiatov <max.desiatov@gmail.com <mailto:max.desiatov@gmail.com>> wrote:

Hi Tony,

This is very interesting caveat. Is there a plan to get this documented anywhere? I haven't seen any documentation for Swift Foundation published publicly anywhere akin to how it's done for other APIs at https://developer.apple.com/reference/\.

With best regards, Max.

With respect to the NSObject requirement: It’s really more of a known issue than a permanent limitation.

To over summarize the situation: NSKeyedArchiver (the Objective-C one) puts a private category on NSObject and assumes all objects respond to those messages after that.

We don’t really have documentation for swift-corelibs-foundation beyond what we can put in our own headerdoc format there. That would be something I would really appreciate help on if anyone is interested in contributing.

- Tony

On 26 Oct 2016, at 18:11, Tony Parker via swift-corelibs-dev <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote:

Hi Sai,

We do have basic support for keyed archiving and unarchiving in swift-corelibs-foundation on Linux. The limitation is that the NSCoding protocol cannot be applied to Swift struct types, only class types. On Darwin, the class also must be a subclass of NSObject. This last limitation may not exist on Linux, but you should be aware that if you encode a non-NSObject subclass on Linux then you would not be able to decode it on Darwin.

- Tony

On Oct 26, 2016, at 4:07 AM, Sai Kanduri via swift-corelibs-dev <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote:

Hi Tony,

From your comments on Pull Request #574 I understand that we cannot archive/un-archive non-NS objects using NsKeyedArchiver & NSKeyedUnarchiver.I s my understanding correct ..? Does this means that archiving and un-archiving of swift types is not supported on Linux ?

-Sai Hema

_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Luke Howard
web <http://lukehoward.com/> / facebook <Facebook; / soundcloud <https://soundcloud.com/lukehoward/> / spotify <https://open.spotify.com/artist/3duTXsC49HoPt4f4EySDKf>

Luke Howard
web <http://lukehoward.com/> / facebook <Facebook; / soundcloud <https://soundcloud.com/lukehoward/> / spotify <https://open.spotify.com/artist/3duTXsC49HoPt4f4EySDKf>