Policies for coding

[Gustavo Niemeyer]

On Mon, Aug 26, 2013 at 11:50 PM, Tim Penhey <tim.penhey at canonical.com> wrote:
> 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.

The comments were made with awareness of your underlying point. See
the prior emails in the thread.

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

Exactly, and this is a broad convention that ignores what the types
are, and whether it makes any sense to use an interface for them or
not. The tone of this thread also broadens this even further:

"Prefer exporting functions and interfaces to structures - unless
there is a very good reason why the structure should be exported."

"And that's why we should generally prefer to return interfaces --
because the cost of doing so and not needing to is negligible, but the
cost of doing after the fact approaches the prohibitive with alarming
stealth and speed."

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

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

The standard library is a significant body of code that implements the
http server and client that backs dl.google.com. It has a TLS
implementation, an ssh server and client, template languages, regular
expression support, a parser/scanner/formatter/printer/builder/ast for
the Go language, and so many other non-trivial things.

Thinking "We know better. We're doing large complex systems." is a
dangerous trap. It's buying a pass to do large complex stuff that
ignores prior experience.

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

That's actually the point. Twisting Go to look more like X (C++, tape,
whatever) isn't solving problems.


gustavo @ http://niemeyer.net