Currently users cannot express whether a field may be NULL or not. The current implementation is a mixed bag: strings are always initialized to NULL, lists and maps are always initialized to a valid list or map object and references are always initialized to NULL.
Up until now, null was not considered a valid value for lists and maps, however, for some types this incurs a lot of overhead as special initialization is required, while the list might actually not (or sparsely) be used. Therefore, the new implementation should allow lists and maps to be NULL.
The following table describes the effect of NOT_NULL on members of the various nullable types:
type
default
NOT_NULL
reference
initialized to NULL
initialized to NULL, must be set to not-null value before DEFINE
string
initialized to NULL
initialized to NULL, must be set to not-null value before DEFINE
any
initialized to NULL
initialized to NULL, must be set to not-null value before DEFINE
Currently users cannot express whether a field may be NULL or not. The current implementation is a mixed bag: strings are always initialized to NULL, lists and maps are always initialized to a valid list or map object and references are always initialized to NULL.
Up until now,
nullwas not considered a valid value for lists and maps, however, for some types this incurs a lot of overhead as special initialization is required, while the list might actually not (or sparsely) be used. Therefore, the new implementation should allow lists and maps to be NULL.The following table describes the effect of NOT_NULL on members of the various nullable types:
corto_llobjectcorto_rbobject