My experience is that there is a very strong and compelling case to be made for a preference for using interfaces on *large* or *complex* structures particularly those which get used widely throughout a codebase. There is also a strong case for what the java people called PoJo (Plain Old Java Objects) -- the tools used to manage complexity generally add some complexity themselves, and that complexity. Interfaces in Go are a pretty lightweight tool, and can be used *fairly liberally* without making big complicated mess of things. They do provide clean *well understood* ways to define a contract between producer and consumer and therefore add some documentation value, as well as making it cleaner to implement a testing strategy around the principle of "define and test the contract."
On the other hand, sometimes the simplest contract is the best one. And a simple structure is easier than an object, let alone an interface. We made a lot of mistakes in TurboGears but the decision to have controller methods just return a dictionary of key value pairs was the best thing we did. The results were easy to test, easy to understand, unambiguously simple. --Mark Ramm On Mon, Aug 26, 2013 at 10:33 PM, Gustavo Niemeyer <gust...@niemeyer.net>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. > > > 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.bo...@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 > > -- > Juju-dev mailing list > Juju-dev@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju-dev > >
-- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
