Right ... Stupid me. I knew I was missing something obvious. On Mon, Apr 6, 2009 at 8:08 PM, Ray Cromwell <[email protected]> wrote:
> > 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 -~----------~----~----~----~------~----~------~--~---
