Sounds awesome. Here's the existing code we are using which shows the problem:
The portable (non-GWT) interface http://code.google.com/p/gwt-chronoscope/source/browse/trunk/chronoscope/src/main/java/org/timepedia/chronoscope/client/data/json/JsonDataset.java The wrapper http://code.google.com/p/gwt-chronoscope/source/browse/trunk/chronoscope/src/main/java/org/timepedia/chronoscope/client/browser/json/GwtJsonDataset.java The Overlay http://code.google.com/p/gwt-chronoscope/source/browse/trunk/chronoscope/src/main/java/org/timepedia/chronoscope/client/browser/json/JsonDatasetJSO.java Obviously, I would like to discard the middle class and simply write: public class JsonDatasetJSO extends JavaScriptObject implements JsonData { ... } -Ray On Fri, Dec 12, 2008 at 3:05 PM, Bruce Johnson <br...@google.com> wrote: > Ray, great timing. Bob was just talking about having started a patch to > allow this. > @Bob: care to comment? > > On Fri, Dec 12, 2008 at 6:01 PM, Ray Cromwell <cromwell...@gmail.com> wrote: >> >> So, I've got these JSON formats that I use both in my Android code and >> my GWT code. I originally implemented them as Overlay JSOs, and there >> are classes that consume these OverlayJSOs to configure other parts of >> the app. However, this makes the consumption code (which is really >> quite generic and portable) unable to run in non-GWT environments. >> >> Thus, I need the consumption code to be able to consume interfaces >> instead. I refactored the Overlay JSOs into interfaces (e.g. >> JsonDataset) and provided a wrapper implementation (GwtJsonDataset) >> that uses private overlay types. I then implemented a J2SE version >> which uses the org.json APIs, which runs in the servlet/android >> versions. >> >> However, it slightly annoys me that: >> >> 1) I have to use a wrapper, so all of the generated consumption code >> looks like "foo.jso.range" instead of "foo.range" >> 2) There is never more then one implementation of the interface active >> in a GWT compile, so it is trivially type-tighten-able to the >> implementation class. >> >> Couldn't the JSO restrictions checker, as a first pass, visit every >> instantiation of interfaces implemented by the JSO, and verify that >> only a single concrete type of the interface is instantiated? This >> would allow JSOs to implement interfaces as long as there is >> effectively only one implementation active. >> >> I'm thinking the logic would go something like this: >> >> for each interface of JSO >> lookup all implementing classes in oracle >> for each implementating class >> find all types instantiated >> if > 1, error >> >> Now, this can change subject to pruning passes, but I would settle for >> the restriction that only one concrete instantiation must exist prior >> to DCE/Pruning. >> >> -Ray >> >> > > > > > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
