+1 for option #2. An interface that can only ever be implemented once seems very limited in usefulness.
On Wed, Jan 7, 2009 at 10:30 AM, BobV <[email protected]> wrote: > > I've working on a branch that allows JavaScriptObjects to implement > interfaces with methods. Due to the lack of polymorphic dispatch of > JSOs, for a given method-bearing interface, there can be exactly one > JSO type implementing the interface. The question at hand is whether > or not to allow N-many regular Java types to also implement that > interface. > > The choices are: > > ---- ONE ---- > > @SingleImpl > interface Person { > String getName(); > } > > class JsoPerson extends JavaScriptObject implements Person { ... } > // It is an error to define any other type that implements Person, > including anonymous types > // subclassing JsoPerson is OK > > > ---- TWO ---- > > @SingleJsoImpl > interface Person { > String getName(); > } > > class JsoPerson extends JavaScriptObject implements Person { ... } > // It is an error to define any other JSO type that implements Person > // subclassing JsoPerson is OK > > class RegularPerson implements Person { ... } > (new Person() { ... }) > // But you can have as many non-JSO types implementing Person > > > > Tradeoffs: > - Scenario one is more restrictive, but calling ((Person) > x).getName() can always be statically resolved to one method > - Land-mines with anonymous types > > - Scenario two allows a JSO implementation to inter-operate with regular code > - Only land-mine would be in declaring a second JSO type > - ((Person) x).getName() would be more expensive to dispatch if > type-tightening doesn't occur; modulo optimizations, it would look > like "x.typeId$ ? x.getName() : getName$(x)" > - This dispatch penalty applies only to interfaces with a JSO > implementation and one or more regular implementations and > type-tightening occurs. > - Would be doing polymorphic dispatch anyway, this just adds a > ternary expression > > > I'm favoring scenario two because it provides the developer > significant additional flexibility. Consider the following where you > get a payload from the server in JSON format, but also want to edit > some of the resulting objects. > > @SingleJsoImpl > interface Person { > String getName(); > } > > final class JsoPerson extends JavaScriptObject implements Person { > protected JsoPerson() {} > public native String getName() /*-{ return this.name; }-*/; > } > > class MutablePerson implements Person { > private String name; > public MutablePerson(Person copyFrom) {this.person = copyFrom.getName();} > public String getName() {return name;} > public void setName(String name); > } > > -- > Bob Vawter > Google Web Toolkit Team > > > > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
