title: Structural typing and polymorphism in Go - Writing a method that can operate on two types having the same fields
body: <p>I started looking into Go after playing around with structural typing in other languages like Scala and OCaml, and I'm trying map some of the idiomatic techniques between the languages.  Consider the following types</p>
  
  <pre><code>type CoordinatePoint struct {
      x int
      y int
      // Other methods and fields that aren't relevant
  }
  
  type CartesianPoint struct {
      x int
      y int
      // Other methods and fields that aren't relevant
  }
  </code></pre>
  
  <p>Let's say we'd like to write a method which operates on both of these types to compute their polar coordinate representations, <code>func ConvertXYToPolar(point XYPoint) PolarPoint</code>.  If the <code>CartesianPoint</code> and <code>CoordinatePoint</code> types defined getter and setter methods for the <code>x</code> and <code>y</code> fields we could define <code>XYPoint</code> as a common interface with those methods, allowing us to operate on both types, but as it stands, interfaces cannot declare fields, only methods.</p>
  
  <p>Based on this, I have a few questions:</p>
  
  <ol>
  <li>What is the idiomatic way of handling this in Go?</li>
  <li>Can it be done without modifying the existing types?</li>
  <li>Can we retain type safety, i.e. avoid defining <code>ConvertXYToPolar</code> without using the empty interface type as the parameter and manually converting?</li>
  <li>If interfaces and implicit interface satisfaction are the primary tools for polymorphism in Go, is the forbiddence of fields in interface definitions limiting?</li>
  <li>Are getter/setter methods commonly defined on structs to circumvent this limitation?</li>
  <li>Is there a compelling reason behind the design decision <em>not</em> to support fields in interface definitions?</li>
  </ol>
  
  <p>I find the simplicity of embedded types, implicit interface satisfaction, and interface-based polymorphism to be a <em>very</em> simple and appealing combination of techniques to promote code reusability and maintainability, but forbidding fields in interface definitions makes Go's structural typing capabilities somewhat limited from my perspective.  Am I missing a simple solution?</p>