You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Creating a main issue to track this work, as it has been asked multiple times, is probably hindering the adoption of go-toml v2.
The main difficulty of building this feature is modifying the unmarshaler in a way that allows it to retrieve actual bytes from the parser for the current target element without impacting performance.
The good thing is that solving this problem will also make implementingtoml.RawMessage pretty easy (#796)!
In my opinion, the work should probably be carried out in this order:
Add the ability to retrieve the offset in the TOML document where a node's data starts. The recent merge of Comments support in unstable/Parser #860 introducing Position should help with that.
Make the Decoder detect that its current target implements toml.Unmarshaler, then keep calling the parser until it finishes its current structure.
Record the first node's start offset and the last node's end offset to retrieve the raw data from the input document.
Feed the raw data to the UnmarshalTOML method.
Part 2 is probably the most difficult to pull off; the unmarshaling and parsing code is somewhat intertwined – though thanks to the intermediate partial AST design, separating both should be doable. The hard part is keeping the same performance level when decoding non-Unmarshaler targets and trying not to fully duplicate the Decoder (otherwise, it's twice the maintenance work :)).
Attention should also be given to detecting that the type implements toml.Unmarshaler. There's likely going to be a performance penalty there until some parser generation is implemented (#669, #758), but we should aim to minimize the impact of that check.
The text was updated successfully, but these errors were encountered:
Creating a main issue to track this work, as it has been asked multiple times, is probably hindering the adoption of go-toml v2.
The main difficulty of building this feature is modifying the unmarshaler in a way that allows it to retrieve actual bytes from the parser for the current target element without impacting performance.
The good thing is that solving this problem will also make implementing
toml.RawMessage
pretty easy (#796)!In my opinion, the work should probably be carried out in this order:
Position
should help with that.Decoder
detect that its current target implementstoml.Unmarshaler
, then keep calling the parser until it finishes its current structure.UnmarshalTOML
method.Part 2 is probably the most difficult to pull off; the unmarshaling and parsing code is somewhat intertwined – though thanks to the intermediate partial AST design, separating both should be doable. The hard part is keeping the same performance level when decoding non-Unmarshaler targets and trying not to fully duplicate the Decoder (otherwise, it's twice the maintenance work :)).
Attention should also be given to detecting that the type implements
toml.Unmarshaler
. There's likely going to be a performance penalty there until some parser generation is implemented (#669, #758), but we should aim to minimize the impact of that check.The text was updated successfully, but these errors were encountered: