The thing with default methods is that while the code may not "break" in the sense of "will not compile", it may very well break in the sense of "issues runtime panic", or even worse: "does the wrong thing".
I do agree all of this can be quite painful, but I'm not so sure that default methods are the right solution.
> and there is no canonical way to document that A satisfies B
Surely that is wrong:
package satisfy
type I interface { foo(); }
type S1 struct { a int; }
type S2 struct { a int; }
func (s *S1) foo() { s.a = 1; }
var _ I = (*S1)(nil);
var _ I = (*S2)(nil);
Then we get:
$ go build ./satisfy.go
# command-line-arguments
./satisfy.go:7:11: cannot use (*S2)(nil) (value of type *S2) as type I in variable declaration:
*S2 does not implement I (missing foo method)
I think the one really useful suggestion here is at the end of the article. Having some way for the compiler to know that a struct satisfies a particular interface, and thereby create a fast path that sidesteps reflection would be marked performance improvement (and avoid the need for caching).
TBH, anything that can make interface casting faster/more efficient in go would be a welcome improvement.
Also doesn't this disprove his default methods claim, or have I misunderstood?
package defmeth
type I interface { foo(); }
type defs struct { }
func (s *defs) foo() { }
var _ I = (*defs)(nil);
type usage struct { defs; a int; }
var _ I = (*usage)(nil);
I’ve used flag.Value a couple of times. That may be one of the few places I agree with the author, but I don’t really care that flag.Value is a pain. It’s just one of many options for handling flags (I use kong for anything non-trivial). If your complaints about Go boil down to command line parsing and not understanding interfaces, you are probably a future gopher in denial.
The thing with default methods is that while the code may not "break" in the sense of "will not compile", it may very well break in the sense of "issues runtime panic", or even worse: "does the wrong thing".
I do agree all of this can be quite painful, but I'm not so sure that default methods are the right solution.
> and there is no canonical way to document that A satisfies B
Surely that is wrong:
Then we get:I think the one really useful suggestion here is at the end of the article. Having some way for the compiler to know that a struct satisfies a particular interface, and thereby create a fast path that sidesteps reflection would be marked performance improvement (and avoid the need for caching).
TBH, anything that can make interface casting faster/more efficient in go would be a welcome improvement.
Also doesn't this disprove his default methods claim, or have I misunderstood?
[dead]
[flagged]
I’ve used flag.Value a couple of times. That may be one of the few places I agree with the author, but I don’t really care that flag.Value is a pain. It’s just one of many options for handling flags (I use kong for anything non-trivial). If your complaints about Go boil down to command line parsing and not understanding interfaces, you are probably a future gopher in denial.