On 27/08/13 15:30, Gustavo Niemeyer wrote: > On Mon, Aug 26, 2013 at 11:50 PM, Tim Penhey <tim.pen...@canonical.com> wrote: >> On 27/08/13 14:33, Gustavo Niemeyer wrote: >>> On Mon, Aug 26, 2013 at 8:03 PM, Tim Penhey <tim.pen...@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.
You are making no sense. Also, Go doesn't have "private" anything, unless by private you mean that anything in the package can touch anything else in the package. >> 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." I can't see why you are arguing against a preference. I'm not saying do this unthinkingly. Just that interfaces as a communication mechanism between packages is preferred. >>>> 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. I didn't say that libraries are trivial. A lot of our own pain has come about how WE use Go. Not Go itself. juju-core separates things into internal packages. We test using different packages so we test the interfaces to the package. I'm trying to come up with some general guidelines that help the juju-core developers make juju better, faster, with better tests. > 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. Actually ignoring the experience of the developers you have on the team who have built large successful systems in the past is equally stupid. I struggle to understand why you thing preferring interfaces for package boundaries is "large complex stuff" ? >> 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. Right. I'm trying to use facilities that Go has to solve our problems. Tim -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
