I see an underlying philosophical question here related to how GWT helps
developers produce the fastest code.
A) One view is that we only allow constructs that generate fast code (e.g.
your option #1); that is, we disallow flexibility that could harm efficiency
if used.
B) The other view is that we do generally allow for more flexibility (e.g.
your option #2) but advise developers that they'll get better performance if
they are willing to not use the extra flexibility.
Probably most people would say (B) seems obviously better, and I basically
agree. However, in a large program that has a high performance bar, it is
totally impractical to enforce "not using the extra flexibility" anywhere in
the code base. Thus, a size and performance hit is likely to sneak in
despite a desire to not let it. And that's what concerns me.
I think we should establish a pattern for safeguards, though which a
developer can state his/her intention and the compiler can warn if the
intention isn't honored by the code base.
We've discussed a family of quasi-unsafe flags, for example:
-Xunsafe:disableCastChecking -Xunsafe:ignoreArrayStoreException
...
We could provide the same sort of thing for global intentions:
-Xintention:monomorphicSingleImpl
-Xintention:smallestPossibleScript
....
Back to your question, Bob: we could use your solution #2 and also provide
the "monomorphicSingleImpl" intention flag. If the flag is set, then the
compiler would warn you if your code actually produces polymorphic single
impls, allowing you to weed them out.
Does anyone buy that reasoning? An important related question is whether
these things are actually compiler flags or whether they are module
settings. I think they are actually more appropriate as the latter.
-- Bruce
On Wed, Jan 7, 2009 at 10:30 AM, BobV <b...@google.com> 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
-~----------~----~----~----~------~----~------~--~---
