ora
ora copied to clipboard
rana
Simpler logging
Continuing the hijacked #82
The easiest change is to provide an Infof and Debugf function, which is used by the default EmpLgr Logger. logger.patch.gz This is a little bit awkward (we will have two ways to configure logging), but has minimal API change, and backwards compatible.
The bigger, but more concise change would be to discard the Logger, and have only Debugf and Infof. But this is a backwards-incompatible change.
Maybe there is a third route: have the Logger interface as is, but USE it differently: have Debugf and Infof vars settable, with the default values for them using the actual Logger. This way both the logger implementation and the Debugf var can be changed, the results will be as awaited. But this needs more think-through...
How about add Debugf, Infof, remove the existing logger and mark it as version 4 for gopkg.in? On Apr 19, 2016 12:48 AM, "Tamás Gulácsi" [email protected] wrote:
Continuing the hijacked #82 https://github.com/rana/ora/issues/82
The easiest change is to provide an Infof and Debugf function, which is used by the default EmpLgr Logger. logger.patch.gz https://github.com/rana/ora/files/225443/logger.patch.gz This is a little bit awkward (we will have two ways to configure logging), but has minimal API change, and backwards compatible.
The bigger, but more concise change would be to discard the Logger, and have only Debugf and Infof. But this is a backwards-incompatible change.
Maybe there is a third route: have the Logger interface as is, but USE it differently: have Debugf and Infof vars settable, with the default values for them using the actual Logger. This way both the logger implementation and the Debugf var can be changed, the results will be as awaited. But this needs more think-through...
— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/rana/ora/issues/83
Yup, that's the easiest and most clear solution! But if we create a new version, do we have anything other we want to change in the API?
Rana Ian [email protected] ezt írta (időpont: 2016. ápr. 19., K, 18:30):
How about add Debugf, Infof, remove the existing logger and mark it as version 4 for gopkg.in? On Apr 19, 2016 12:48 AM, "Tamás Gulácsi" [email protected] wrote:
Continuing the hijacked #82 https://github.com/rana/ora/issues/82
The easiest change is to provide an Infof and Debugf function, which is used by the default EmpLgr Logger. logger.patch.gz https://github.com/rana/ora/files/225443/logger.patch.gz This is a little bit awkward (we will have two ways to configure logging), but has minimal API change, and backwards compatible.
The bigger, but more concise change would be to discard the Logger, and have only Debugf and Infof. But this is a backwards-incompatible change.
Maybe there is a third route: have the Logger interface as is, but USE it differently: have Debugf and Infof vars settable, with the default values for them using the actual Logger. This way both the logger implementation and the Debugf var can be changed, the results will be as awaited. But this needs more think-through...
— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/rana/ora/issues/83
— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/rana/ora/issues/83#issuecomment-212006341
Its really up to you. I don't have anything to change at the moment.
Adding breaking changes is eased by using gopkg.in. the only drawback is that the go major version becomes more of a minor version when using gopkg.in, but that seems fine.
What do you think? On Apr 19, 2016 12:09 PM, "Tamás Gulácsi" [email protected] wrote:
Yup, that's the easiest and most clear solution! But if we create a new version, do we have anything other we want to change in the API?
Rana Ian [email protected] ezt írta (időpont: 2016. ápr. 19., K, 18:30):
How about add Debugf, Infof, remove the existing logger and mark it as version 4 for gopkg.in? On Apr 19, 2016 12:48 AM, "Tamás Gulácsi" [email protected] wrote:
Continuing the hijacked #82 https://github.com/rana/ora/issues/82
The easiest change is to provide an Infof and Debugf function, which is used by the default EmpLgr Logger. logger.patch.gz https://github.com/rana/ora/files/225443/logger.patch.gz This is a
little bit awkward (we will have two ways to configure logging), but has minimal API change, and backwards compatible.
The bigger, but more concise change would be to discard the Logger, and have only Debugf and Infof. But this is a backwards-incompatible change.
Maybe there is a third route: have the Logger interface as is, but USE it differently: have Debugf and Infof vars settable, with the default values for them using the actual Logger. This way both the logger implementation and the Debugf var can be changed, the results will be as awaited. But this needs more think-through...
— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/rana/ora/issues/83
— You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub https://github.com/rana/ora/issues/83#issuecomment-212006341
— You are receiving this because you commented.
Reply to this email directly or view it on GitHub https://github.com/rana/ora/issues/83#issuecomment-212072722
Why is DrvCfg.Env.StmtCfg.Rset not a pointer? Why not called as RsetCfg? And Env is why not EnvCfg in this chain? I feel a little inconsistency here. (If we create a new version, I'd like to clean such things up a little bit).
Go for it! I don't recall answers to your questions. Feel free to improve On Apr 20, 2016 12:57 AM, "Tamás Gulácsi" [email protected] wrote:
Why is DrvCfg.Env.StmtCfg.Rset not a pointer? Why not called as RsetCfg? And Env is why not EnvCfg in this chain? I feel a little inconsistency here. (If we create a new version, I'd like to clean such things up a little bit).
— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/rana/ora/issues/83#issuecomment-212312177