I had a question and when I looked through the FAQ I saw it:
https://golang.org/doc/faq#covariant_types. But could anyone give more
information specifically as to why Go does not have "covariant types"? What
is
the motivation behind that choice? If Go did support it, what kind of
problems
could crop up?
The motivation for this question: The main reason I like interfaces in Go is
that they are a way to make use of the dependency inversion principle
without
having to write a lot of code. All you have to do is define the interface
which some type happens to implement, have your code depend on the
interface,
and pass in the concrete type where the interface is used. Then your code is
decoupled from the implementation of the concrete type. But sometimes a
concrete type you want to write an interface for has methods which return
another concrete type and in those situations I don't want to write an
interface because then the interface would need to use those concrete types
in
its definition and since, in my mind, the whole point of the interface was
to
avoid relying on concrete types this defeats the purpose. For instance
consider this code:
```
package main
import "fmt"
func main() {
var c Interface = TypeIDontOwn(10)
c.Print()
c.Incr().Print()
}
type TypeIDontOwn int
func (c TypeIDontOwn) Print() {
fmt.Println(c)
}
func (c TypeIDontOwn) Incr() TypeIDontOwn {
return c + 1
}
type Interface interface {
Print()
Incr() Interface
}
```
I want this to work but Go complains because:
```
TypeIDontOwn does not implement Interface (wrong type for Incr method)
have Incr() TypeIDontOwn
want Incr() Interface
```
In my mind this should work though because although the signature for Incr()
is different I would argue that TypeIDontOwn does satisfy Interface and
therefore it should satisfy Interface's method signature for Incr(). I can't
make TypeIDontOwn's Incr() signature match Interface's Incr() method because
I'm pretending that this is a scenario where I don't own the type. And I
don't
want Interface's Incr() method signature to match TypeIDontOwn's because
then
I'd be relying on TypeIDontOwn and the whole point of using interfaces in
the
first place was so I did not have to be coupled to any concrete types. It
seems then my only option in this scenario would be to create a "wrapper"
type
around TypeIDontOwn and have it satisfy Interface, but it would be nice if I
could get this behavior for free.
So why does Go not support this? I feel like it could make interfaces more
useful, but maybe I'm missing something. Are there dangers or difficulties
lurking which I'm not aware of?
Thanks!
Lucas
--
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.
