Allow custom deserialization with callbacks

[smola]

Some time ago I forked this project into src-d/gcfg. The goal of the fork was using this library to parse git's config files in src-d/go-git.

The main change is this one: src-d@bdb40b4

It adds a new function to parse a file using a custom callback. This callback can be used to implement deserialization to custom structures or just other kind of deserialization logic.

Is this something that you would consider adding? If that is the case, it'd be great to read your feedback and I'd be willing to make a PR.

[speter]

Thanks for the feedback. It's great to see this package used in diverse scenarios. But I don't think adding callbacks is the right long-term solution here (even though it was probably the most effective short-term solution.) I've thought for a long time that the parsing of the input and the setting of values are too tightly coupled in gcfg and should be split into two distinct phases, but I haven't got around to implementing this. (Mostly because I didn't have good motivation -- now with your use case I do.) If this is done, there would be some internal representation of the parsed input that could also be consumed by projects such as go-git. Even though it's a bit more work initially in both gcfg and go-git, I believe this would lead to better code in both projects in the long run.

…

On Thu, Oct 25, 2018 at 7:38 PM Santiago M. Mola ***@***.***> wrote: Some time ago I forked this project into src-d/gcfg <https://github.com/src-d/gcfg>. The goal of the fork was using this library to parse git's config files in src-d/go-git <https://github.com/src-d/go-git>. The main change is this one: ***@***.*** <src-d@bdb40b4> It adds a new function to parse a file using a custom callback. This callback can be used to implement deserialization to custom structures or just other kind of deserialization logic. Is this something that you would consider adding? If that is the case, it'd be great to read your feedback and I'd be willing to make a PR. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#16>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAbhgfv_LSIy91ybiq5AXqBvDlMu7UM7ks5uoZSrgaJpZM4X5_QC> .

[smola]

@speter Thanks! Sounds good. We can adapt to the new approach in go-git once it lands. We'll keep our fork at the moment, since it's very low maintenance for us (just 1 fix since it started).