> 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.
