> On 8 Jan 2015, at 06:54, Leonard Rosenthol <[email protected]> wrote: > >> That's the benefit of the current approach that after the deep cloning >> the imported page is independent from the source page. > > And that’s what you (IMO) want to maintain. > > Once you copy the object(s) to the new document they are, in fact, new > objects and should be treated that way. They may still point back to data > in the original file (since you don’t need to copy the stream until write > time (aka COW model)) but the object itself is now part of the tree of the > new document.
This is not the Java way of doing things, if I add an object to a list I can share that object among other lists and mutate it at a later point. Likewise, I can add a COSDictionary to a COSDocument and share that among other COSDocuments and mutate it at a later point. That’s exactly what a Java developer would expect - if they are to produce a copy of an object, then they expect to call some sort of clone() API to do so. There’s no real way around this in Java - it’s fundamental. > One thing you might want to think about is shallow vs. deep copies. In > many of the other libraries, the CosObjCopy() method (or equivalent > thereof) offers the option to copy the full tree/structure or just the top > level - this distinction is useful in a variety of operations. Perhaps > that might help here as well. Yes, we’re doing a deep copy and there’s no real need for it, a shallow copy would work just as well - that’s what I’m trying to advocate. I’m going a bit further and pointing out that in Java there’s no need for any copy. If the user wants to share objects between documents, then Java enables that by default and we’d have to work very hard to stop them doing something natural. It sounds like we should probably add a copy() API to our COS objects rather than having it in an easily-overlooked utility class, and also deepCopy() for COSStreams. But there’s no need to use them, unless the user actually desires a copy - it’s perfectly valid to share COS objects in Java. — John
