[gwt-contrib] Comment on OverlayTypes in google-web-toolkit
Comment by bobbysoares: Scottb, I was suggesting for example having new MyObject(...) be replaced with MyObject.newInstance(...) automatically (where newInstance would be a method supplied by the developer which returns an instance of the class, possibly natively, after calling the JS constructor). Maybe it's not a great solution. Rjrjr, the non-JSO implementation would add overhead though, right? That's what i wanted to avoid, without giving up constructors, if possible. If not, i'll still live. For more information: http://code.google.com/p/google-web-toolkit/wiki/OverlayTypes --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Comment on OverlayTypes in google-web-toolkit
Comment by cromwellian:
It would be interesting to consider Constructor() as being rewritten to a
static method with an implicit call to createObject() and all references to
this rewritten to this$static. e.g.
public Foo(int x, String y) {
this.x = x;
this.y = y;
}
rewritten to
public static Foo consFoo(int x, String y) {
Foo this$static=createObject.cast();
this$static.x=x;
this$static.y=y;
return this$static;
}
Moreover, you could consider any field declarations on Foo as having
implicit native methods for getting and assignment. Thus,
public Foo extends JavaScriptObject {
int x;
}
would implicitly have methods like
native int getX() /*-{ return x; }-*/;
native void setX(int x) /*-{ this.x=x; }-*/;
although these would only exist in the compiler/AST (purely for
visualization purposes here). That way, needless boilerplate accessors in
JSOs would be eliminated.
All of the usual JSO restrictions would apply. This is purely syntactic
sugar. Stuff like field initializers and super calls in the constructor
would still be banned (for now), although they could be supported via
additional rewriting logic (like moving initializers into the synthesized
factory method and super calls invoking super class factory methods which
take this$static parameters)
For more information:
http://code.google.com/p/google-web-toolkit/wiki/OverlayTypes
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Comment on OverlayTypes in google-web-toolkit
Comment by rj...@google.com: JSOs can now implement interfaces. Rather than wishing for a constructor on your JSO, you can implement to an interface and have your JRE code provide an alternative, non-JSO implementation. For more information: http://code.google.com/p/google-web-toolkit/wiki/OverlayTypes --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Comment on OverlayTypes in google-web-toolkit
Comment by bobbysoares: I see use for public constructors in Overlay-Types when wrapping around JS libraries. I say this because when it's necessary to enable the overlayed types to be constructed from Java, where the choice is between the use of a plain Java wrapper class or an Overlay-Type with a factory method, i still prefer using the Overlay-Type with a factory method. If developers will end up adding factory methods to Overlay Types to get around the constructor issue then maybe we should consider allowing public constructors that compile to static factory methods. Am i missing some detail that makes this approach less viable or not feasible from an implementation perspective? For more information: http://code.google.com/p/google-web-toolkit/wiki/OverlayTypes --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Comment on OverlayTypes in google-web-toolkit
Comment by sco...@google.com: Regarding the hosted mode implementation: we should actually mangle the method name into com_google_Person$someMethod. Adding the dollar-sign is the convention for synthetics. For more information: http://code.google.com/p/google-web-toolkit/wiki/OverlayTypes --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
