Policies for coding

[Tim Penhey]

On 27/08/13 14:33, Gustavo Niemeyer wrote:
> 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.

You are completely missing the point that was being illustrated.

We are talking about the problems of creating complicated structs with
private members from different packages.

>> 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.

Large complex software systems are different to libraries.

> 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.

Sure, but as we are told often, juju-core is the largest public Go
project out there.  Large systems hit different problems to small systems.

I'm not trying to alienate Go programmers of any sort.  I'm trying to
make sensible decisions that work for juju-core.


> 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.

And I'll show you how to use a tape turing machine.  This isn't the point.

Tim