On 12 March 2018 at 17:53, Maverick Woo <maverick....@gmail.com> wrote: > Hi, > > I am exploring a pattern to achieve a desirable aspect of vtable in Go. For > now please put the vtable consideration aside, and see an example I have put > together for this post: > > https://play.golang.org/p/ctkwGuYGqiy > > In the example, there is a "typo" in the spelling of a method name ("Buuuug" > instead of "Bug"), and that typo caused the generate code to exhibit an > infinite recursion in method lookup. > > This infinite recursion looks reasonable to me and I consider the Go > compiler & runtime to be doing the right thing here. My question is: is > there a way to *statically* catch this typo, in the same spirit as the > ineffective attempt at the end of the playground example (a "var _ type > assertion")?
This is an interesting edge case that you've run across, and I've done similar things in the past but I don't buy your motivational example. Putting an embedded recursive reference to a value within the value itself seems to be asking for trouble to me. Go emphasises "has-a" relationships over "is-a" relationships, and ISTM that you're trying hard for the latter when the former provides a straightforward path to doing what you want. For example: https://play.golang.org/p/b2J05LxzGpT (stripped down to a single file so that it works in the Go playground). Specifically, by changing the Print function to a function from a method, we allow it to run on any value that implements the Shape interface without being a method on Shape itself. That is, Print *has a* Shape, rather than being part of a Shape. Does that not work for you? cheers, rog. -- 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. For more options, visit https://groups.google.com/d/optout.
