> 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.
No, it has nothing to do with a "typo". I removed the Buuuug() method and infinite recursion still occurs at runtime because Go cannot find a concrete implementation of bug and you have self-referenced your main struct that needs an implementation of VTable in the VTable field of your struct. Provide a concrete implementation of Bug() and that problem goes away. https://play.golang.org/p/zA1U47AAgI0 Le lundi 12 mars 2018 12:20:56 UTC, Maverick Woo a écrit : > > 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")? > > The situation here essentially involves a type that does not provide a > method to override a declared method in an embedded interface value. I > recall method promotion for interface values is dynamic, and so I am not > hopeful there would be a static solution for this "typo" problem. However, > I thought at least I can ask for advice here. :> > > Thanks! > > Maverick > > P.S. This thread is really not intended to discuss vtable in Go and I am > not advocating that this "vtable pattern" in the playground example is the > right approach to write Go in every situation where dynamic dispatch is > needed. In fact, in my experience, this is far from the truth and the > typical "accept an interface value as an argument" works in most cases. > However, I would also hope we don't stigmatize a concept just because it is > not the best approach in every case. To see one possibly-compelling use > case of this pattern in a concrete toy example, I have written more in > https://www.reddit.com/r/golang/comments/83qboe/the_vtable_pattern_in_go/ > and the associated GitHub repo. I hope the README.md in the repo would be > sufficient to explain a niche case when this pattern may be useful. Please > feel free to leave you comments there too! Thanks! > > -- 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.