5 ms·
as I understand it (and I may be misunderstanding it), contracts are exactly like interfaces, except the type of parameters/return values is left to the impleme
by marcus_holmes 7y ago
as I understand it (and I may be misunderstanding it), contracts are exactly like interfaces, except the type of parameters/return values is left to the implementation.
So an interface of "adder" would look like:
type adder interface {
Add(int) int
}
and it would only be able to support adding an int to something, and returning an int.
Doing this:
func AddStrings(a adder, b string) string {
return a.Add(b)
}
will break
A contract for "adder" would look like:
contract adder(T) {
T Add (T) T
}
You can then use this in a function by:
func addTheThings(type T adder)(t1, t2 T) T {
return t1.Add(t2)
}
which can then use any type that has an Add method
//can't extend native types, so we have to create an alias and extend that
type Addstring string
func (a Addstring)Add(b Addstring) Addstring {
return a+b
}
func (a Banana)Add(b Banana) Banana {
return Banana{a.Count + b.Count}
}
then your "addTheThings" function can operate on strings (via the Addstring type) and Bananas, and anything else that fulfills the contract. So the original example:
func AddStrings(a adder, b string) string {
if as,ok := a.(Addstring); ok {
return a.Add(b)
}
//raise an error here
}
On a separate note, why is "contract" becoming a keyword instead of "type foo contract {}"?
Making the common business concept of "contract" a keyword is likely to break backward compatibility for some code bases
- dilap 7y ago> On a separate note, why is "contract" becoming a keyword instead of "type foo contract {}"? I was wondering about this too. It also just feels really weird since it's a different construction than any of the other types. Maybe the thinking is because a contract is not a type? But so what... On first blush, it also feels weird that type is coming _before_ the type arguments, rather than after -- since types for normal arguments come after the argument. E.g., Map(T, U type)(t []T, f func(T) U) []U feels much more consistent than Map(type T, U)(t []T, f func(T) U) []U no? (Perhaps it complicates parsing, though?)
- DangitBobby 7y agoI think calling it a type would be confusing. It's not a type, it's a description of a behaviors of potential types.
- ithkuil 7y ago"var n int" means "in this scope, declare variable n to be if type int". "type T adder" means "in this scope, declare T to be a type adhering to the adder contract"
- dilap 7y agoGood way to think of it.
- DangitBobby 7y agoThey address backwards compatibility in the document. It will only be a keyword in certain contexts so that any valid go1 code will still be valid go2 code.
- marcus_holmes 7y agoah, I missed that. Cool
- gigatexal 7y agoWell done. I understood that. Thank you.