On Fri, Jul 3, 2020 at 3:16 PM, Ian Lance Taylor <i...@golang.org> wrote:
> > The trick with this kind of approach is understanding what should > happen if the type with a package-specified method is converted to an > empty interface type, handed to some other package, and then in some > way handed back to the original package. Does the package-specified > method survive these conversions? Why or why not? Also, how does > type reflection work: can it discover such methods? Can it discover > them in a different package? There may be answers here but they don't > jump out as obvious. > In order to be consistent, the package-qualified method should survive conversions the same way as a normal method would. Even unexported methods do this. Interface satisfaction is a property of the type, not the value. This would require that packages have the ability to register any extension methods they define in the runtime representation of an external type somehow. However, package-qualified methods would never satisfy an unqualified method constraint in an interface, regardless of any interface conversions. Reflection would be able to discover these methods, provided the package defining them is linked into the binary. Importing a package for its side effects is already a thing, so that aspect shouldn't be too surprising. You also don't have the same visibility concerns you have with unexported methods; there's no particular issue with a package discovering an extension method defined in a different package at runtime. One thing that I've found tricky is how to deal with embedding. If these methods can be promoted, then you have method instances which no single package owns. The package that defines a struct embedding a type and a package defining extension methods on the same type don't necessarily know about each other. I would think that, in order to have extension methods be promoted, it would need to be done explicitly. If you could embed a type like pkg(T) which layered the extension methods defined in package pkg on top of the inherent methods of type T, then extension methods wouldn't need to be promoted in the general case. Otherwise, extension methods most likely just wouldn't be promoted. -- 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 golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CANjmGJt5NHHPU%2BR86GOyRYp1DgEHfZCB5PzbfRQoMTmMtV34mg%40mail.gmail.com.
