<div dir="ltr">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. <div>
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." </div>
<div><br></div><div>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.</div>
<div><br></div><div><span style="color:rgb(136,136,136)">--Mark Ramm</span></div><div><span style="color:rgb(136,136,136)"><br></span></div><div><div class="gmail_extra"><div class="gmail_quote"><span style="color:rgb(80,0,80)">On Mon, Aug 26, 2013 at 10:33 PM, Gustavo Niemeyer </span><span dir="ltr" style="color:rgb(80,0,80)"><<a href="mailto:gustavo@niemeyer.net" target="_blank">gustavo@niemeyer.net</a>></span><span style="color:rgb(80,0,80)"> wrote:</span><br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><div class="gmail_extra">
<div class="gmail_quote">
On Mon, Aug 26, 2013 at 8:03 PM, Tim Penhey <<a href="mailto:tim.penhey@canonical.com" target="_blank">tim.penhey@canonical.com</a>> wrote:<br>> Information hiding and abstracting implementation details from use is<br>
> pretty general.<br><br><blockquote class="gmail_quote " style="margin:0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;border-right-width:1px;border-right-color:rgb(204,204,204);border-right-style:solid;padding-left:1ex;padding-right:1ex">
</blockquote>Go has private variables, private constants, private types, private<br><blockquote class="gmail_quote " style="margin:0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;border-right-width:1px;border-right-color:rgb(204,204,204);border-right-style:solid;padding-left:1ex;padding-right:1ex">
</blockquote>functions, private methods, private fields, and private constants.<br><blockquote class="gmail_quote " style="margin:0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;border-right-width:1px;border-right-color:rgb(204,204,204);border-right-style:solid;padding-left:1ex;padding-right:1ex">
</blockquote>None of that depends on interfaces.<br><br>> Yes this can be fine, but for very small, well defined types.<br><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
</blockquote>It can be fine for a wide variety of types, as you can find out<br><blockquote class="gmail_quote " style="margin:0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;border-right-width:1px;border-right-color:rgb(204,204,204);border-right-style:solid;padding-left:1ex;padding-right:1ex">
</blockquote>throughout the standard library and in lots of other projects out<br><blockquote class="gmail_quote " style="margin:0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;border-right-width:1px;border-right-color:rgb(204,204,204);border-right-style:solid;padding-left:1ex;padding-right:1ex">
</blockquote>there.<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
</blockquote><br><blockquote class="gmail_quote " style="margin:0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;border-right-width:1px;border-right-color:rgb(204,204,204);border-right-style:solid;padding-left:1ex;padding-right:1ex">
</blockquote>Ultimately, you'll have the power to decide what conventions the juju<br><blockquote class="gmail_quote " style="margin:0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;border-right-width:1px;border-right-color:rgb(204,204,204);border-right-style:solid;padding-left:1ex;padding-right:1ex">
</blockquote>code base follows, but remember that by choosing awkward conventions,<br><blockquote class="gmail_quote " style="margin:0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;border-right-width:1px;border-right-color:rgb(204,204,204);border-right-style:solid;padding-left:1ex;padding-right:1ex">
</blockquote>you'll be losing the good will from the community, and may well end up<br><blockquote class="gmail_quote " style="margin:0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;border-right-width:1px;border-right-color:rgb(204,204,204);border-right-style:solid;padding-left:1ex;padding-right:1ex">
</blockquote>loosing the good will of team members that are used to coding in Go as<br><blockquote class="gmail_quote " style="margin:0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;border-right-width:1px;border-right-color:rgb(204,204,204);border-right-style:solid;padding-left:1ex;padding-right:1ex">
</blockquote>the rest of the world sees it.<br><br>On Mon, Aug 26, 2013 at 8:46 PM, Ian Booth <<a href="mailto:ian.booth@canonical.com" target="_blank">ian.booth@canonical.com</a>> wrote:<br>> Another +1 for using interfaces instead of structs directly is that using<br>
> interfaces is AFAIK the only way to achieve polymorphism in Go, since with<br>> structs, methods are statically bound at compile time.<br><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
</blockquote>Binding methods statically at compile time is actually a pretty good<br><blockquote class="gmail_quote " style="margin:0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;border-right-width:1px;border-right-color:rgb(204,204,204);border-right-style:solid;padding-left:1ex;padding-right:1ex">
</blockquote>thing for lots of reasons. Polymorphism is just a tool to achieve<br><blockquote class="gmail_quote " style="margin:0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;border-right-width:1px;border-right-color:rgb(204,204,204);border-right-style:solid;padding-left:1ex;padding-right:1ex">
</blockquote>something. Show me a problem and I'll show you a way to not use<br><blockquote class="gmail_quote " style="margin:0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;border-right-width:1px;border-right-color:rgb(204,204,204);border-right-style:solid;padding-left:1ex;padding-right:1ex">
</blockquote>polymorphism.<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
</blockquote><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
</blockquote><br><blockquote class="gmail_quote " style="margin:0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;border-right-width:1px;border-right-color:rgb(204,204,204);border-right-style:solid;padding-left:1ex;padding-right:1ex">
</blockquote>gustavo @ <a href="http://niemeyer.net" target="_blank">http://niemeyer.net</a><br><br>--<br>Juju-dev mailing list<br><a href="mailto:Juju-dev@lists.ubuntu.com" target="_blank">Juju-dev@lists.ubuntu.com</a><br>
<div><div>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju-dev" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju-dev</a><br>
</div></div></div><br></div>
</div></div></blockquote></div><br></div></div></div>