Policies for coding

[Gustavo Niemeyer]

On Mon, Aug 26, 2013 at 8:03 PM, Tim Penhey <tim.penhey at canonical.com> wrote:
> Information hiding and abstracting implementation details from use is
> pretty general.

Go has private variables, private constants, private types, private
functions, private methods, private fields, and private constants.
None of that depends on interfaces.

> Yes this can be fine, but for very small, well defined types.

It can be fine for a wide variety of types, as you can find out
throughout the standard library and in lots of other projects out
there.

Ultimately, you'll have the power to decide what conventions the juju
code base follows, but remember that by choosing awkward conventions,
you'll be losing the good will from the community, and may well end up
loosing the good will of team members that are used to coding in Go as
the rest of the world sees it.

On Mon, Aug 26, 2013 at 8:46 PM, Ian Booth <ian.booth at canonical.com> wrote:
> Another +1 for using interfaces instead of structs directly is that using
> interfaces is AFAIK the only way to achieve polymorphism in Go, since with
> structs, methods are statically bound at compile time.

Binding methods statically at compile time is actually a pretty good
thing for lots of reasons. Polymorphism is just a tool to achieve
something. Show me a problem and I'll show you a way to not use
polymorphism.


gustavo @ http://niemeyer.net