From Linx 6 moving forward, Linx now handle types the same as normal programming languages. This means that a type now needs to be initialized before you interact with it. If the type is not properly initialized you might get the following error: “Object reference not set to an instance of an object.”
By default, Linx will initialize the very top level of a type. However, child properties may not be initialized. For example, if I use a type containing another type with a list in it, the list will not be initialized by default. The developer will have to do this. It also depends on the scenario and where the type is used in Linx. For example, when types are used in parameters, this will not be necessary. However, when a type is declared inside a function (as an object to be used in that function), you might need to initialize some properties manually.
For example, I have a type with fields A (string), B (string) and ListC (list), when attempting to add to the list, I will get an error:
When this is done, we can add to the list as needed. You can initialize lists with [ ] and types with {}
Some things to keep in mind:
An integer is not allowed to be NULL. So if you’ve got an Int that is NULL, you can’t, for instance, count + 1 to it. You will have to declare it as 0 before hand.
Each list in a Type needs to be initialized in order to be used.
You can construct a separate list and then assign that list to the one in your type without initializing the original list. This can only be done as long as the main Type is initialized.
Is there a reason behind this design choice? The first time i encountered this error i was thrown off quite a bit by it as it deviates from the expected behavior. Nor was it all that easy to find the reasoning behind it, along with the solution needed to fix it. Not to say the solution wasn’t a super easy fix once i understood what was happening.
Would it be possible as an alternative to include a Boolean checkbox in the properties panel of any types that may require initialization before usage? In any use case I’ve come across it was the same pattern of just throwing in the [] or {}. Which is a predictable pattern that is unlikely to change. Yet i think it would also be an easily missed step while developing. I think having a checkbox would be more intuitive. The visual cue would be much more obvious.
Strings, Custom Types, and Lists defaults to null. All other types are not nullable and will default to their respective minimum value. As an example, integer defaults to 0.
When creating a nullable type through the Linx Designer, it defaults to an empty string, empty object {}, or empty list [ ]. (The empty string changes to null as soon as you click in the Value field and navigate away - this might be a bug).
Properties on Types do not get initialized automatically.
The main reasons for these design choices are
Not automatically initializing properties: Automatically initializing properties of Types that refer to themselves, like Person with a Father property of Person, results in a stack overflow because we try to create an infinite number of Person.
Initializing the top-level value (the one dragged in by the developer): Seems like a sensible default. The variable can be set to something else, or its properties can be set without having to initialize it yourself.
Providing defaults when defining a type makes sense. There are also larger changes to our type system that could be beneficial, like following C# (sort of) and making all types nullable or not nullable and making it easier for the compiler and designer to pick up potential problems.
