That works until 1) you don't want to export the value types 2) the return values aren't simple structs but slices or maps because []x is not a []X even if x implements X.
> the return values aren't simple structs but slices or maps because []x is not a []X even if x implements X.
I assume this is because on is an array of struct pointers and the other is an array of fat pointers, since Go has reified interfaces (unlike higher-level languages).
This affects discoverability, though. Your unexported type won't have public documentation. So you end up having to publish an interface anyway (even if you don't return it) or document in words what the method set looks like.
formerly_proven|4 months ago
I assume this is because on is an array of struct pointers and the other is an array of fat pointers, since Go has reified interfaces (unlike higher-level languages).
bpicolo|4 months ago
That’s exactly the pattern I use for most Go development
kbolino|4 months ago