What do do about public methods

[MatthewJohn]

From #434 (reply in thread):

Regarding the usage of our methods in other golang projects we should have a look at the golang project layouts
See https://github.com/golang-standards/project-layout/tree/master/pkg/_your_public_lib_

At moment we don't reflect that and we are not really intentionally exposing any functions to reuse in other projects.

What are your thoughts regarding that? (we could split that discussion from this thread if needed)

[MatthewJohn]

I think we need to ask the core question whether we want to allow it. Given that some people are using it, maybe it's a missed opportunity, but certainly has quickly taken a hit on refactoring :)

I think, though, if we do want to be more explicit about making methods public, we should definitely re-evaluate some of the practices - in particular the use of Fatal - I strongly think that (at least to make the methods usable) we should start returning errors. On the flip side, this also makes testing in this code base much easier.
I'd like to raise this relatively quickly, because as part of #435, we're deprecating some of the public methods and adding new ones - if we could, I'd love to update the signatures of the new methods to return err (even if, for now, it doesn't ever return an error), meaning that we can slowly switch to returning errors without having to break those signatures again :)

[yermulnik]

What are your thoughts regarding that?

I have zero nays on that (especially given there are already projects that utilize (or would be keen to utilize) tfswitch as lib) =)
Either way I'd rely upon you guys and @warrensbox to decide on this as I'm not a Golang guy. This probably should be a lower priority than other tasks and we can target a specific release to officially introduce public methods, package, or whatever this is called in Devs world 😄
On the other side it seems we already can (or even should) start "transforming" code towards this option, as @MatthewJohn mentioned.

I strongly think that (at least to make the methods usable) we should start returning errors.
[…]
I'd love to update the signatures of the new methods to return err (even if, for now, it doesn't ever return an error), meaning that we can slowly switch to returning errors

That's a good point.
My concern is for us to not end up with a half-re-factored code with a mix of functions (methods) that throw Fatals whilst others return errors <- if you guys are up to be gradually re-factoring code in a targeted manner or along with other changes, then why not.

[MatthewJohn]

I reckon we could tackle them relatively quickly - but I'd like to update the signatures before publishing them in #435 , so they don't need to be changed again. I have a local change to add them, which I'm holding off committing. But if it's the direction that we'd like to go in, I'd be happy to add them

[yermulnik]

@warrensbox