Depends on the nullable switches being used in Spring.inc
We once thought that it is a good idea to have implicit operator from Variant to Nullable and back. However the compiler outsmarted that by allowing wrong types to be assigned to a lets say Nullable like a string because it turned the string into a variant and assigned that to the nullable which only caused an invalid conversion exception at runtime.
I added two switches called IMPLICIT_NULLABLE and UNSAFE_NULLABLE (they both are defined by default to provide backwards compatibility but the methods being ifdefed by those are causing deprecated warnings). You can read the comments above them in the Spring.inc
Depends on the nullable switches being used in Spring.inc
ReplyDeleteWe once thought that it is a good idea to have implicit operator from Variant to Nullable and back. However the compiler outsmarted that by allowing wrong types to be assigned to a lets say Nullable like a string because it turned the string into a variant and assigned that to the nullable which only caused an invalid conversion exception at runtime.
I added two switches called IMPLICIT_NULLABLE and UNSAFE_NULLABLE (they both are defined by default to provide backwards compatibility but the methods being ifdefed by those are causing deprecated warnings). You can read the comments above them in the Spring.inc
In Spring 1.2 I added a type called Nullable with a const called Null (to not conflict with the Variant Null) but eventually found a way for 1.2.1 to make it possible to assign nil but not any other reference variable (see http://delphisorcery.blogspot.de/2017/05/how-to-create-operator-overload-that.html).
TL'DR: The preferred way is to assign nil as of the coming release 1.2.1 (eta really soon)
Stefan Glienke thanks for the explanation!
ReplyDelete