-
Notifications
You must be signed in to change notification settings - Fork 212
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bring back toml.Unmarshaler #873
Labels
feature
Issue asking for a new feature in go-toml.
Comments
#940 added only partial support, this shouldnt be close probably |
Thanks for catching it, didn't mean to close this issue! |
Will type Unmarshaler interface {
UnmarshalTOML(data []bytes) error
} v.s. type Unmarshaler interface {
UnmarshalTOML(value *Node) error
} I'm suspicious of feasiblity of the former one for nested table. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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: