Hi folks,
I think there may be two "bugs" in the discussion here.
The first one is definite and it is the "Bg" in the original playground
example, which is intended to illustrate a bug made by the programmer: the
intended "Bug" method is missing, either due to a typo in an attempt, or
simp
Hi Christopher,
Sharp eyes! Yes, in the current shape example, they are the same and so
Dynamic() is redundant. Thanks for pointing it out!
I have reviewed my projects and there are indeed some niche scenarios where
I have the Dynamic() method of a descendant at, say, depth 2 return a
VTable t
How is this a bug? I don't think Go compiler can guess the intent of the
developer at compile time.
I don't think that qualifies as bug.
Le mardi 13 mars 2018 16:48:32 UTC-3:30, Christopher Sebastian a écrit :
>
> @prades.marq , The solution that you pointed out is already obvious to
> everyo
@prades.marq , The solution that you pointed out is already obvious to
everyone. Maverick was not asking "how" to solve the problem. He is
pointing out an interesting corner-case bug in the Go runtime.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" g
> In the example, there is a "typo" in the spelling of a method name
("Bg" 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 Bg() method and
infinite recursion still occurs a
Hi Maverick, this is an interesting VTable pattern to think about.
I have a question about your Dynamic() method. As far as I can see, these
two expressions would always be equal:
myShape.Dynamic()
myShape.VTable
...So why go through the trouble of defining Dynamic() at all? Is there
