Expansion of the Metadata mapping system

[TheBoxyBear]

As observed with @Memsworth the current metadata system is quite flawed and prone to invisible breaking changes through the use of the UnidentifiedData hash table. As new keys become mapped, these keys no longer appear in the table, giving the false impression that the data is missing unless the user code is updated to use the new property.

This could be resolved by supporting string-based indexing, supporting both mapped properties and the has table to remain backwards compatible with user code.

Additionally, metadata could benefit from user-created mappings through types deriving from Metadata. This would however require the attribute system to be fully autonomous, with no hardcoded property references in parsing or serializing. If this is not possible, the Metadata object could always expose its own parser and serializer to use.

If performance is a concern regarding the heavy use of reflection, attribute search results could also be cached on a per-type basis.

[TheBoxyBear]

To consider for string indexing: A mapped value can easily be returned as a string with ToString, however assigning a value is more complex and not guaranteed to always be possible such as if the string is invalid for the target type. If it's to be assumed string indexing is to be used when a key is not mapped, maybe the key should be added to the hash table when set. With this approach however, the hash table should take priority when serializing to use the manually set value even if the key is mapped. The table should also have priority when indexing to retrieved a previously set value.

This has a slight downside of the set value not used by functions relying on the property to get the value. However, such functions would only exist and be callable in versions of the library where the property exists. Regardless, string indexing could potentially be used in a dynamic way that would be difficult for the user to make the necessary refactors beyond switching to reflection to access the properties.

Something to also consider is if a new function sets the value of a newly added mapping, which wouldn't be reflected when obtaining by indexing if previously set be indexing. Maybe the hash entry should be removed in property setters.

[TheBoxyBear]

Also on string indexing is the origins. A recent PR allows for duplicate keys of different file origins, useful if a value should have different formatting based on file format. However, how should duplicates be handled when indexing? Maybe this should be made opaque, adding table entries with all file flags, but still exposing the table for manual control of format flags and adding duplicates. Using the table directly would already be more acceptable considering the priority defined in the previous comment.

[TheBoxyBear]

For autonomous attributes:

.chart has an example of an oddly formatted value through the year written as ", value". To allow autonomous attributes, they should also support formatting strings. Either one for the string around the value and one for the value itself (string argument of ToString) or a single one in the form ", {0:format}". for the chart year. This syntax is supported by string interpolation and its implementation should be investigated.

[TheBoxyBear]

Although attributes could be made autonomous for serialization, Parsing solely from attributes could be far more complex, considering the parsing of various data types and assigning values inside structures such as Chater. Although supporting custom mappings through derived Metadata types, the complexity compared to the possible use-cases does not seem worth it considering the library is open-source, allowing Metadata to be extended directly.

It could be worth considering again once available on NuGet where using a modified source would be more involved for the user. At that stage, it could be worth looking into supporting custom parsers/serializers provided at the time of call rather than relying on fully autonomous attributes.