callSuper() is private, so B's invocation is not polymorphic, and should not reference C's callSuper()
On Mon, Apr 6, 2009 at 4:50 PM, Vitali Lovich <[email protected]> wrote: > > > On Mon, Apr 6, 2009 at 7:13 PM, John Tamplin <[email protected]> wrote: > >> The attached patch, relative to trunk r5191, adds a new tests which fails >> only in web mode and only for the JsniSuper case. It appears the problem >> isn't directly related to super, but rather with making calls to private >> methods polymorphic rather than virtual dispatch. This is the bug I ran >> into with the CurrencyListGenerator changes I committed and then had to roll >> back. >> >> Ie: >> >> public class A { >> public void foo() {} >> } >> >> public class B extends A { >> public void foo() { callSuper(); } >> private void callSuper() { super.foo(); } >> } >> >> public class C extends B { >> public void foo() { callSuper(); } >> private void callSuper() { super.foo(); } >> } >> >> B's foo will always call B's callSuper, even when this is actually a C. >> We handle this properly for Java code, but not when foo is a JSNI method. > > Woudn't this cause infinite recursion when this is actually a C & using > virtual dispatch? > > c.foo -> c.callSuper -> b.foo -> c.callSuper -> b.foo -> c.callSuper etc. > > If it's a polymorphic call, I believe the call graph looks like: > c.foo -> c.callSuper -> b.foo -> b.callSuper -> a.foo > >> >> >> -- >> John A. Tamplin >> Software Engineer (GWT), Google >> >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
