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
-~--~~~~--~~--~--~---
