Stream: implementers
Topic: null attributes in fhir-net-api
Mattias Flodin (May 03 2017 at 10:45):
I'm confused about when I can expect attributes to be null or not in fhir-net-api. It seems that lists, such as Patient.Relationship can never be null because the property creates the list implicitly when it is null. On the other hand, Patient.animal.species which is a mandatory attribute does not automatically create an instance when the attribute is accessed.
Is there a general principle for when attributes can be null?
Michele Mottini (May 03 2017 at 10:47):
Lists are never null - everything else (that is nullable) can be null
Mattias Flodin (May 03 2017 at 10:51):
Alright, thanks
Mattias Flodin (May 03 2017 at 10:58):
There seems to be a redundancy here then. The generated CopyTo() code checks whether list properties are null. But they can never be null since the property implementation always creates the list if it is null.
Mattias Flodin (May 03 2017 at 10:59):
additionally, it calls DeepCopy() and then passes the result into the List constructor, so it's actually creating a copy of a copy
if(Relationship != null) dest.Relationship = new List<Hl7.Fhir.Model.CodeableConcept>(Relationship.DeepCopy());
Mattias Flodin (May 03 2017 at 11:04):
Ah no, not an efficiency issue, more like a consistency issue. List<Resource>.DeepCopy doesn't create a copy of the List, it returns a LINQ enumerable is based on the original object.
Yunwei Wang (May 03 2017 at 19:52):
I always check null or empty before enumerating list.
Last updated: Apr 12 2022 at 19:14 UTC
