Divide encoding and decoding infos into separate classes (one per type) and make them replaceable by the user? Like with the JsonSerializer?

[Apollo3zehn]

No description provided.

[Blackclaws]

I have a related request. Right now when using record datatypes you need to provide a default constructor that takes no arguments for PureHDF to actually restore the datatype. As such a constructor might not make a lot of sense (if any) outside of a deserialization context it would be great if it could be protected/private instead of public and PureHDF could similar to the JsonSerializers simply call it using reflection.

[Apollo3zehn]

Related to #64

Yes that would be nice to have! I think this feature is a great addition to PureHDF but I will not be able to put much time into in soon. With first stable version released a few days ago I need to take a break and work on other projects first :-( I think I can work on it in autumn, but that is just a rough estimation.

[Blackclaws]

Given that you are super responsive and fix issues very quickly you deserve some time off as well.

Is this something that you'd be able to review a PR on if I happen to get the time in to make one?

[Apollo3zehn]

Yeah sure, that would be quite helpful :-)

[Blackclaws]

While I haven't gotten around to it yet due to a massive lack of time :) its still on my list of things I'd like to contribute.

I also found another thing that might be helpful to add to a general possibly attribute based annotation for types.

Whether structs should include properties instead of just fields.

Mainly thigns like record structs run into the problem that they auto create properties but expose no fields, therefore PureHDF fails on those while they are extremely helpful constructs.

[Apollo3zehn]

I like your idea, it makes perfectly sense to have a functionality like that. At the same time in the settings there should also be the possibility to provide a user-defined function which takes a System.Type as input parameter (your record struct for example) and returns a boolean which indicates if properties should be included (and another method for fields). The currently existing settings would then become fallback or global settings which are only applied when no attribute or user defined function is available.

This way we cover both uses cases:

1. The type is controlled by the developer and can be modified with attributes. In that case the attribute solution is perfect
2. The type is from an external library and with that function we are still able to control the serialization