Isn’t this a symptom of structural/duck typing where interfaces are not declared? In Java for all its faults this wouldn’t happen because you’d be forced to implement all the interfaces.
The logic uses a type assertion to safely verify if the value backing the provided io.Reader interface also implements the io.ReaderFrom interface. If it matches, then it will use the more efficient implementation
if rf, ok := dst.(ReaderFrom); ok {
return rf.ReadFrom(src)
}
> In Java for all its faults this wouldn’t happen because you’d be forced to implement all the interfaces.
I don't think I would go that far. In Java, many libraries make heavy use of the `instanceof` keyword, which is more or less the same as Go type assertions.
Yes, but contrary to Go, if you change an interface it will be a compiler error if additional methods are missing, unless they have default implementations.
In Java type assertions are mostly used when writing code pre-generics style, like downcasting from a common subclasse into the actual implementation, not to see if an interface is supported, as it is a given from the type system.
How is a package level interface check a “language hack”? They are straight forward and provide a user the same compile time guarantees as the Java implements keyword.
Yes, essentially duck typing. See https://github.com/golang/go/blob/65504872cbca64d77f45828409...
The logic uses a type assertion to safely verify if the value backing the provided io.Reader interface also implements the io.ReaderFrom interface. If it matches, then it will use the more efficient implementation
> In Java for all its faults this wouldn’t happen because you’d be forced to implement all the interfaces.I don't think I would go that far. In Java, many libraries make heavy use of the `instanceof` keyword, which is more or less the same as Go type assertions.