On Fri, Aug 29, 2008 at 7:02 PM, Ray Cromwell <[EMAIL PROTECTED]> wrote:
> This is what I effectively have today, but my point was that JSO's > can't subclass CanvasImpl. It is not the Canvas object that needs to > be a JSO, it's the CanvasImpl object, because it is the CanvasImpl > object that has the JSNI methods on it which directly interact with > the browser's native canvas. > Yeah, but it doesn't have to be that way, right? Instead of your CanvasImpl having a JavaScriptObject ctx field, you just pass the thing in as a parameter. canvas.moveTo(10, 3) -> CanvasImpl.$moveTo(canvas, 10, 3) -> canvas.moveTo(10, 3) You should get both the inlining and the API you want, with the implementation being deferred bound. It's just that the actual JSO contains only delegators and your JSNI lives in the deferred bound class. > Here's a question. What if CanvasImpl was a JSO with a bunch of stub > methods (non-final), and each subclass of CanvasImpl overrode every > stub method with a final method, would it still work? Actually, the > final isn't needed. In a sense, if due to a deferred binding, only a > single concrete subclass implementation exists, and no method dispatch > on CanvasImpl is ever polymorphic, then everything is "effectively" > final and it should work. Couldn't the JSO restriction checker be a > little more lenient and just prove in each permutation that no virtual > dispatches occur? > In theory, something could probably be workable, but it'd require more extensive changes than simply relaxing the checks. --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
