On Thu, Oct 18, 2018 at 11:35 AM Ian Lance Taylor <[email protected]> wrote:
>
> On Wed, Oct 17, 2018 at 11:58 AM, Burak Serdar <[email protected]> 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 [email protected].
For more options, visit https://groups.google.com/d/optout.
