Quoting Burak Serdar (2018-10-19 12:34:44)
> Re: Ian Denhardt's proposal:
>
> I agree that it handles all the cases in the official proposal,
> but I think the syntax is too verbose and reminds me of
> Java. For instance, the "sorting" example can be written using
> the "like" keyword as:
>
> Template:
>
> type orderedSlice []like (int,string)
>
> func (s orderedSlice) Len() int { return len(s) }
> func (s orderedSlice) Less(i, j int) bool { return s[i]<s[j] }
> func (s orderedSlice) Swap(i, j int) { s[i], s[j] = s[j], s[i] }
>
> // There is no need for an OrderedSlice function
>
> Concerete use:
>
> type mySlice orderedSlice []int64
>
> v:=mySlice{1,2,3}
> sort.Slice(v)
This example in my proposal was intended to show the minimal change
needed from the draft design, but I also mentioned that you actually
didn't need `orderedSlice` at all to sort slices. If you combine it
with Eric's proposal for operator overloading, you can just write
v := []int64{1,2,3}
sort.Slice(v)
..with no boilerplate type/method definitions, or casts, at all.
> However, one limitation of using interfaces to specify contracts
> is that you can't use a struct type as a basis for your
> contract. For instance, going back to the linked list example:
>
> type Node like struct {
> next *Node
> }
>
> With interfaces as contracts, this becomes:
>
> type Node(type E) interface {
> GetNext()
> SetNext(*Node(E))
> }
This is true; exposing the next-pointer structure of a linked list
through an interface is more verbose. However I'm not convinced there
are good uses for this; Can you provide an example where such a template
would actually be useful?
--
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.
