This is related to the issue I discussed in another email about common
subexpression elimination and wrappers.
If I had a Layer interface/delegator which delegated to a GWT.create()
call which returns a JSO, the JSO would still need to implement an
interface. Imagine that I want to turn this:
layer.ctx.moveTo(100,100);
into
ctx.moveTo(100,00);
I can do this today with a JSO that overlays the JS object returned
from element.getContext('2d');
However, if I want to have a drawing interface that might use JSOs
targeting Canvas, Flash, or SVG objects in the browser, I'm guessing
you're talking about doing something like this:
public class Canvas {
CanvasJSO impl = GWT.create(CanvasImpl.class);
public void moveTo(int x, int y) { impl.moveTo(x,y); }
}
Great, this will get perfectly inlined to "ctx.moveTo(x,y);"
The problem is, how do I make a do I make a GWT.create() call return
disjoint JSO types that are usable by a single delegator?
In the above, you see that I am declaring the impl field as a
CanvasJSO. But if GWT.create(CanvasImpl.class) can also return a
FlashJSO or a SVGJSO, which have native canvas emulation, what do I
declare the type of this impl field as? I can't make those three JSOs
implement an interface, nor can I make them inherit from a abstract
base class, or use overrides.
The current solution is not to use JSOs but to use wrappers, which
means all those methods end up looking like this:
function moveTo(this$static, x, y) {
this$static.ctx.moveTo(x,y);
}
where ultimately, the JsInliner reduces this to:
localVar.ctx.moveTo(x,y);
It's not terrible, but I was looking for a way to remove the wrapper
references until CSE appears in the compiler.
-Ray
On Fri, Aug 29, 2008 at 11:47 AM, Scott Blum <[EMAIL PROTECTED]> wrote:
> Ray, can you help me understand why the delegator pattern doesn't do it for
> you? Take for example the 1.5 dom.client library, if you look at
> Element/Node you'll notice several calls that are delegated to
> dom.client.DOMImpl, which is deferred bound.
>
> On Fri, Aug 29, 2008 at 3:36 AM, Ray Cromwell <[EMAIL PROTECTED]> wrote:
>>
>> Your example looks correct. I heavily 'drank the koolaid" of Overlay
>> types earlier this year and have not regretted it. To the extend that
>> there are areas where I'd like to use them, but can't, because of
>> their inability to implement interfaces
>>
>> . In particular, when using Deferred Binding to wrap native browser
>> objects, sometimes I need a JSO created differently for each DB. Each
>> JSO is "effectively final" because only one concrete type of the
>> interface ever exists in any permutation, so theoretically it's
>> possible for the JSO design to work within these restrictions, but a
>> little hairy. (essentially, if type-tightening fails, you're screwed)
>>
>> The classic example is Canvas drawing. I have an interface which
>> exports drawing methods (moveTo, lineTo, transform, etc) One
>> implementation might be a wrapper around the CanvasRenderingContext2D
>> from the <CANVAS> tag. Another might be a Flash, SVG, or Silverlight
>> implementation.
>>
>>
>> -Ray
>>
>> On Fri, Aug 29, 2008 at 12:26 AM, Ian Petersen <[EMAIL PROTECTED]> wrote:
>> >
>> > On Fri, Aug 29, 2008 at 3:05 AM, Reinier Zwitserloot
>> > <[EMAIL PROTECTED]> wrote:
>> >> I don't use GWT-Serialization to talk to my server. The server sends
>> >> timestamps as milliseconds. I'd like to turn these milliseconds into
>> >> javascript Date objects.
>> >>
>> >> How do I accomplish this?
>> >>
>> >> As I mentioned when long emulation was on the table, timestamps are
>> >> one of those numbers which are not representable with ints, but they
>> >> fit perfectly in the range where doubles still represent integral
>> >> numbers without loss of precision.
>> >
>> > I don't think you want to use longs--someone measured them at 250
>> > times slower than JS doubles, or something like that. I think you
>> > want the following:
>> >
>> > public final class JSDate extends JSO {
>> >
>> > protected JSDate() {
>> > }
>> >
>> > public static native create(double millis) /*-{
>> > return new Date(millis);
>> > }-*/;
>> >
>> > // implement relevant date methods here, like getYear:
>> >
>> > public native int getYear() /*-{
>> > return this.getYear();
>> > }-*/;
>> > }
>> >
>> > Not sure though--I haven't used the new overlay stuff myself, and I
>> > typed the above directly into the browser without testing.
>> >
>> > Ian
>> >
>> > >
>> >
>>
>>
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~----------~----~----~----~------~----~------~--~---
