Stream: dotnet
Topic: Deepcopy on list based properties
Jeffy Mathew Jose (Nov 08 2018 at 15:02):
I was trying to use Resource.CopyTo to merge few resources, but stumbled on copying null or empty properties
If a resource has a uninitialized property which is a list , say Identifier, the identifier on target resource is replaced with a new empty list.
This is surprising given that , if it some other kind of property, say Code, the code on target is replaced only if code is not null.
Upon digging deeper, I found that list property is always initialized to an empty list if null.
- Either, we should check null on underlying backing field before copying
- Or, we should check for null or empty on property which are of type list
Thoughts?
Ewout Kramer (Nov 08 2018 at 21:05):
Currently, copying literally means overwriting what is in the target, but I can see the usefulness of doing more like a merge. For lists however, you'll always have the problem of deciding whether you want to replace or append, and depending on your use case you'll want one or the other. We could enable the other behaviour by introducing a MergeInto() or somesuch. That operation will almost surely need be controlled by Annotations on the elements to have finegrained control over what to do with lists.
Jeffy Mathew Jose (Nov 09 2018 at 07:12):
If Copyto meant overwriting, why do the properties have a null check before copying?
Different behavior for list and non-list properties is what stumbled me.
List properties will never be null and the check for null during CopyTo is misleading
Btb, I think "merge" was a strong word. I was trying something simpler(kind of overwriting).
I had a template instance with some desired properties(say X) which I copy to a target instance which had other properties(say Y) set. Now If Y was of type list, the CopyTo operation will clear Y.
Michel Rutten (Nov 09 2018 at 10:01):
Hmm, interesting observation. Current implementations of CopyTo only copy non-empty values to the target, i.e. remaining any target property values remain untouched. This seems more of a "merge" operation, whereas copy implies to me that the final target will be exactly equal to source - which isn't the case right now. Maybe we should remove the null checks alltogether and ensure that target.IsExactly(source) after a CopyTo operation?
Brian Postlethwaite (Nov 10 2018 at 23:45):
It is, provided it was empty to start ;)
Jeffy Mathew Jose (Nov 12 2018 at 11:14):
...which is true only when used by DeepCopy. Was the "CopyTo" operation meant to be private/internal helper function?
Ewout Kramer (Nov 19 2018 at 15:41):
I guess. I created it, but that's years ago when I was still a virgin API developer ;-) Now, what do we do with it? [Obsolete] it and think about stuff we'd really want it to do?
Last updated: Apr 12 2022 at 19:14 UTC
