Default initialisers are removed, and properties and state are zero-initialised if not
given a value. This makes the parser simpler for any parsers that want to introspect
data-structures.
At the time this was disallowed for a few reasons:
Soton wanted things as simple as possible to get v4 working as soon as possible.
Imperial was concerned about making the parser more complicated, as for non-Orchestrator
tools it is necessary to fully parse the structure definitions.
The ability to explicitly specify device state initialisers made it somewhat less important to
be able to provide defaults.
You can also set these things up in the OnInit handler if you want.
I see that the v4 versions of plate_heat use struct initialisers, for example:
This is actually not too big a deal if we want to support it. The parsing for
properties/state structs turned out to be pretty easy, and I think defaults
can be supported for those who need to completely parse declarations.
It's also a non-breaking change, as long as we bump the minorFormatVersion.
So if we want to support this in a v4.1 revision then that is quite doable.
It would be nice to support as I (personally) have found it makes things a bit easier. It is definitely not necessary, but a minor version bump would be acceptable.
In the v4 discussions we removed the ability to have default initialisers on property and state declarations in the xml:
https://github.com/POETSII/poets_improvement_proposals/blob/2a355282f3aa3912bdacf4ec50bf25199bdf310d/proposed/PIP-0020-v4-xml.md
At the time this was disallowed for a few reasons:
I see that the v4 versions of plate_heat use struct initialisers, for example:
https://github.com/POETSII/Orchestrator_examples/blob/f184e6d91aee06b3daaa96bba975f5f7e1ad6fb3/plate_heat/plate_heat_type_gals2.xml#L51-L56
This is actually not too big a deal if we want to support it. The parsing for properties/state structs turned out to be pretty easy, and I think defaults can be supported for those who need to completely parse declarations.
It's also a non-breaking change, as long as we bump the minorFormatVersion.
So if we want to support this in a v4.1 revision then that is quite doable.