Hi Eskimo!
yeah... requiremnets make that unworkable. Or at least that's what I thought when I decided i needed an init method, instead of a copy method. I just went through the dataflow, and I didn't run into any roadblocks... maybe this is one of those times that getting a slightly new perspective makes a difference. Anyway... all of this falls where it is because of another Object Oriented Language anyway. NSPasteboardWriting, is the problem. the way
public func pasteboardPropertyList(forType type: NSPasteboard.PasteboardType) -> Any? {
was written, in order to avoid particular nastiness, you can't just make a copy of the root object, otherwise you wind up in the balancing init method:
public required init?(pasteboardPropertyList propertyList: Any, ofType type: NSPasteboard.PasteboardType) {
with the object that was just inited (self) and the copy of a useless object of the same class. You have to transfer, by hand, all of the properties. You have to transfer those properties under any circumstances.
personally I'd rather use a copy method. not allowed here.
what I settled on was making a dictionary, one with all of the properties, for the base object. (subObjects can be left intact, just duplicated in the base dictionary.) then coding it into a Data object, and returning that. Then on init, copying the properties, and in the cases of reference types, just moving them - from the dictionary to the newly minted object. It's an entirely pointless hassle I could do without. Some of those subObjects are interconnected, and I have to reconnect the duplicates, by hand as they are copied.
I thought I had run into a reason you can't simply copy objects relatively early in my process. But I've forged ahead in the meantime, and I "currently" have a solution that "should" work. I'll put down supporting a "copy" protocol on the list for refactoring. at some point in the future.