Author: [email protected]
Date: Wed Jan 14 08:40:10 2009
New Revision: 4447
Modified:
wiki/OverlayTypes.wiki
Log:
Edited wiki page through web user interface.
Modified: wiki/OverlayTypes.wiki
==============================================================================
--- wiki/OverlayTypes.wiki (original)
+++ wiki/OverlayTypes.wiki Wed Jan 14 08:40:10 2009
@@ -4,7 +4,7 @@
Bruce Johnson, Scott Blum, Lex Spoon
== Background ==
-The {{{JavaScriptObject}}} class has been an extremely useful concept
because it provides zero-overhead interoperation with external (typically,
non-GWT) !JavaScript while adding additional value to external !JavaScript
objects by representing them as actual Java types that are amenable to
refactoring, code completion, and Javadoc-style documentation. However,
subclassing {{{JavaScriptObject}}} was not generally supported before GWT
1.5 because we weren't sure if it was the right solution, or if we might
need to evolve it in breaking ways. This document describes the "old
model" prior to GWT 1.5, and the new model, overlay types, which shipped in
GWT 1.5
+The {{{JavaScriptObject}}} class has been an extremely useful concept
because it provides zero-overhead interoperation with external (typically,
non-GWT) !JavaScript while adding additional value to external !JavaScript
objects by representing them as actual Java types that are amenable to
refactoring, code completion, and Javadoc-style documentation. However,
subclassing {{{JavaScriptObject}}} was not generally supported before GWT
1.5 because we weren't sure if it was the right solution, or if we might
need to evolve it in breaking ways. This document describes the "old
model" prior to GWT 1.5, and the new model, overlay types, which shipped in
GWT 1.5 as well as extensions to overlay types that will first ship in GWT
2.0.
The old model used two very different approaches for hosted mode and web
mode, but in both cases the point of interest was the boundary point
between Java and !JavaScript code, when a !JavaScript object passes
into "the Java world". This boundary point was most often the return value
of a JSNI function, but could also occur when a JSNI function accessed Java
code through a field assignment, or by passing parameters to a Java
function called from JSNI.
@@ -189,4 +189,43 @@
Shape s = (Shape) (JavaScriptObject) c; // succeeds always
System.out.println(Shape$.getArea(s)); // prints a double
}
-}}}
\ No newline at end of file
+}}}
+
+== Updates for GWT 2.0 (In-progress DRAFT} ==
+
+Overlay types have demonstrated their utility for producing
type-safe !JavaScript (e.g. the `dom.client` package). It is difficult to
isolate the JSO implementation from consuming code without the use of an
intermediate type due to the restriction on declaring JSO types that
implement interfaces. A new feature in GWT 2.0 will introduce the
single-JSO-implementation, `...@singlejsoimpl`, annotation applied to an
interface type that will allow exactly one JSO subtype to implement that
interface.
+
+=== Example Use ===
+{{{
+...@singlejsoimpl
+interface Person {
+ String getName();
+ String getAddress();
+}
+
+/** The only JSO-based implementation of Person */
+public final class JsoPerson extends JavaScriptObject implements Person {
+ protected JsoPerson() {}
+ public native String getName() /*-{return this.name;}-*/;
+ public native String getAddress() /*-{return this.address;}-*/;
+}
+
+/** Legal to have any number of regular Java types implement the
interface. */
+public class JavaPerson implements Person{ ... }
+}}}
+
+=== Goals ===
+ * Allow increased decoupling of overlay types and consuming code by
allowing an interface to be extracted from the overlay types. _This should
improve the testability and reusability of consuming code, especially in
the common use case of JSO-cum-DTO._
+
+=== Restrictions ===
+The restrictions on overlay types given above still apply, with the
following modifications:
+ * An overlay type may implement any number of interfaces with methods
that are annotated with `...@singlejsoimpl`. _This makes it obvious to the
system which interfaces should have these alternate rules applied._
+ * Any given `...@singlejsoimpl` interface may be implemented by exactly one
overlay type, although that overlay type may be further extended. Any
number of non-overlay types may implement the interface. _This allows any
method defined in the interface to be statically-dispatched in the fallback
case._
+ * If a `...@singlejsoimpl` interfaces extends a non-trivial interface, that
super-interface must also be be annotated with `...@singlejsoimpl`.
+ * The `...@singlejsoimpl` annotation may only be applied to interfaces.
+
+=== Hosted Mode Implementation ===
+
+
+
+=== Web Mode Implementation ===
\ No newline at end of file
--~--~---------~--~----~------------~-------~--~----~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~----------~----~----~----~------~----~------~--~---
