On Tue, 4 Sep 2018, 5:52 pm xingtao zhao, <zhaoxing...@gmail.com> wrote:
My five cents:
1) the methods of the type template are defined by interface style
2) operators are retrieved implicitly from function body
3) function-calls inside are also retrieved implicitly from the function
body
For graph example, we may declare it as:
type Edgeser(type E) interface {
Edges() []T
}
type Nodeser(type N} interface {
Nodes() from, to N
}
type Graph(type Node Edgers(Edge), type Edge Nodeser(Node)) struct { ... }
Yes, that's entirely the solution I would have suggested were I to have
been asked that question a month ago. But since then, contracts have
enlightened me. :-)
The beauty of contracts is that they allow one to bundle up all of those
relationships into one easy-to-call bundle. We no longer have to worry
about the specific type parameters in common between Edgers and Nodesers.
The unique thing that contracts bring is the relationship between several
different types - a contract is a bit like a function that returns several
values - this is something that no other language construct in Go can do,
even after tweaking.
Even if contracts only allowed interface conversions, they'd still be
unique and useful.
Operators and other constructs are syntax sugar - perhaps nice to have but
not essential to contracts, in my view.
On Monday, September 3, 2018 at 4:19:59 PM UTC-7, Ian Lance Taylor wrote:
On Sun, Sep 2, 2018 at 1:08 AM, 'Charlton Trezevant' via golang-nuts
<golan...@googlegroups.com> wrote:
>
> Link: [Getting specific about generics, by Emily
> Maier](https://emilymaier.net/words/getting-specific-about-generics/)
>
> The interface-based alternative to contracts seems like such a natural
fit-
> It’s simple, straightforward, and pragmatic. I value those aspects of
Go’s
> philosophy and consider them to be features of the language, so it’s
> encouraging to see a solution that suits them so well. The author also
does
> a great job of contextualizing the use cases and debate around generics,
> which I found incredibly helpful.
>
> Any thoughts?
It's a very nice writeup.
It's worth asking how the graph example in the design draft would be
implemented in an interface-based implementation. Also the syntactic
issues are real.
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.
--
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.
