On Thu, Oct 18, 2018 at 11:35 AM Ian Lance Taylor <i...@golang.org> wrote: > > On Wed, Oct 17, 2018 at 11:58 AM, Burak Serdar <bser...@ieee.org> wrote: > > > > Instead of specifying the minimal set of operations a type should > > satisfy, why not describe what the type should look like: > > > > func f(in like T) > > I don't see how this approach can handle multiple types that need to > work together in some known way, like the Graph/Node/Edge case in the > design draft.
Still discussing the details, but the graph case in the design draft can look like this: type Node like interface { Edges() []Edge } type Edge like interface { Nodes() (Node,Node) } type Graph like struct { Nodes []*Node } func New(nodes []*Node) *Graph { return &Graph{Nodes:nodes} } The instantiation: type MyNode struct {...} func (m MyNode) Edges() []MyEdge {...} type MyEdge struct { ...} func (e MyEdge) Nodes() (*MyNode,*MyNode) {...} type MyGraph graph.Graph { Nodes []*MyNodes } x:=graph.New(MyGraph)(myNodes) > > Ian -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.