Allow to extend set of parsers
prochac opened this issue · 2 comments
If I would like to add my custom parser I can't!
The env.loader has AddParser method what is unused and imposible to call from outside.
Because env.loader instance is unexported I can create it on my own.
The only instance of env.loader is created by env.newLoader function what is unexported as well.
And the instance is created in env.Load function what is the only thing what is exported from the package at all.
I don't see a point why that (env.loader#AddParser) code even exists if it's unused and unreachable.
If I would like to add my custom parser I can't!
If you want to customize parsing logic for your own types, just implement the TextUnmarshaler interface on that type as stated in the documentation. If you want to implement parsing logic for types from third-party side, just embed the third-party type into your own type and implement TextUnmarshaler on it.
I don't see a point why that (env.loader#AddParser) code even exists if it's unused and unreachable.
This should be the title of your question! :) I am not sure why the code is here. Probably some relict that we have forgotten to remove. Maybe @dcepelik would answer the question better.
Anyway, was your point to start a discussion about it? The general idea is that if you want custom parsing logic, just implement TextUnmarshaler. For built-in go types, it is not possible, that's why there are baked-in default parsers. Do you think such function as AddParser would be useful - i.e. do you have use-case for it? IMO, I think adding another approach how to add parsers would be misleading, so I propose to remove the function completely. Am I missing something?
ACK, I got confused from reading of the package code :) It feels like it's prepared for exposing, but the last step wasn't done.