On Thu, Oct 18, 2018 at 10:48 AM, Burak Serdar <bser...@ieee.org> wrote:
> 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)
Thanks. I note the subtlety whereby the name Edge in the generic code
gets attached to the name MyEdge in the non-generic code, although it
does not appear anywhere in the call to graph.New. There is a type
mapping happening somewhere.
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.
