The value of a time-tagged object can also be an array and this isn't supported yet. There are, I think, some other objects in ASDF schemas that have a similar property--that they can be either array or scalar valued, and this rather impacts the APIs for setting and getting their values.
In the case of time you don't just want an array of asdf_time_t; you still want a single object with a shared format, etc. and just arrays for the value.
One argument might be to make a completely separate struct type for this case, like asdf_time_array_t; however, it's not currently possible to associate a single tag with different extension registrations. This could be done but then there needs to be some particular extension-specific logic for selecting which extension to use based on more information than just the tag.
Another option would just be to fold an optional array value into asdf_time_t, with some flag to to indicate its dimensionality; ugly, but straightforward.
Split this off from #208 since I don't think this is a priority for the 0.1 release.
The value of a
time-tagged object can also be an array and this isn't supported yet. There are, I think, some other objects in ASDF schemas that have a similar property--that they can be either array or scalar valued, and this rather impacts the APIs for setting and getting their values.In the case of
timeyou don't just want an array ofasdf_time_t; you still want a single object with a shared format, etc. and just arrays for the value.One argument might be to make a completely separate struct type for this case, like
asdf_time_array_t; however, it's not currently possible to associate a single tag with different extension registrations. This could be done but then there needs to be some particular extension-specific logic for selecting which extension to use based on more information than just the tag.Another option would just be to fold an optional array value into
asdf_time_t, with some flag to to indicate its dimensionality; ugly, but straightforward.Split this off from #208 since I don't think this is a priority for the 0.1 release.