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?


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.

Reply via email to