Thanks Matt, I'm familiar with the pattern. It might be a good subject for
another thread, specifically comparing this approach to interfaces. It's an
interesting design discussion.
Cheers,
Clinton
On Thu, Jan 25, 2018 at 6:19 AM, wrote:
> Hi Clinton,
>
> Here's an example for the struct of fun
Hi Clinton,
Here's an example for the struct of function
approach: https://play.golang.org/p/F_f0hLNsmSW
These are not key issues, I'm just sharing the path I've been on.
Thanks for sharing Graven here. I'll read those references.
Matt
On Wednesday, January 24, 2018 at 3:57:27 PM UTC-6, matth
You are using interfaces to define a type. The overhead of interface isn’t
necessary to achieve the same goal. I see that github.com/gorilla also uses
this pattern in places. Supporting another tool or providing a mock for
testing is just making a new value of the type.
I do use sub-packages an
Hi Matt, thanks for the review.
Here is some feedback and explanation.
>> Does BuildTool need to be an interface? Having methods on a pointer to
nothing (type GoBuildTool struct{}) seems unnecessary to me.
Interfaces are expressions of functional contract, and have little
dependency or basis
Hi Clinton, here’s a code review.
Does BuildTool need to be an interface? Having methods on a pointer to
nothing (type GoBuildTool struct{}) seems unnecessary to me. Also, why not
have this at the level of package main?
Same with graven/commands, graven/config, graven/domain, graven/util, since
