<when-linkers-include name='xs' />

[Lex Spoon]

There are a couple of different ways that the choice of linker affects
what the compiler should do with runAsync:

1. If the code will be loaded inside a nested function, then variable
and function definitions need to be rewritten if they are referenced
on a different fragment than the one that loads them.

2. If the code could be loaded in violation of the same origin policy,
then a script tag rather than XHR needs to be used to download the
code.

One way to allow this sort of flexibility would be to add methods to
the Linker API. However, it's hard to see what the extensions should
look like. Unless there is a general ability to add new passes via
the Linker API, there would have to be a new method in the API for
each compiler option a linker might ever influence.

Instead, how about allowing deferred bindings to be controlled by the
linker choice? Then, if linker A is chosen, it could flip deferred
binding B. A specific syntax could be as follows:

<replace-with
class="com.google.gwt.core.client.impl.AsyncFragmentLoader.StandardLogger">
<when-type-is
class="com.google.gwt.core.client.impl.AsyncFragmentLoader.Logger" />
<when-linkers-include name="xs" />
</replace-with>

This looks both simple and general. Does this seem reasonable? Does
anyone see a better way?

Lex Spoon

[John Tamplin]

On Mon, Dec 21, 2009 at 5:51 PM, Lex Spoon <sp...@google.com> wrote:

 <replace-with
   class="com.google.gwt.core.client.impl.AsyncFragmentLoader.StandardLogger">
   <when-type-is
class="com.google.gwt.core.client.impl.AsyncFragmentLoader.Logger" />
   <when-linkers-include name="xs" />
 </replace-with>

This looks both simple and general.  Does this seem reasonable?  Does
anyone see a better way?

SGTM. 

--
John A. Tamplin
Software Engineer (GWT), Google

[BobV]

Make add-linker accept conditionals based on module properties? Then rebinds and linkers can have unified predicates.

--Bob (Android)

[Lex Spoon]

On Mon, Dec 21, 2009 at 11:24 PM, BobV <bo...@google.com> wrote:
> Make add-linker accept conditionals based on module properties? Then rebinds
> and linkers can have unified predicates.

Do you mean, instead of doing this:

<add-linker name="xs" />

People would normally do this:

<set-configuration-property name="linker" value="xs" />

Then the "linker" setting influences a bunch of others?

<add-linker name="xs" >
<when-property-is name="linker" value="xs" />
</add-linker>

If that's what you mean, it sounds rather elegant. The thing users
configure are properties, and then everything else including linker
addition is rule-driven.

The main question I have, though, is how to transition to such a
scheme? Users currently write explicit add-linkers all over the
place.

Lex

[BobV]

> The main question I have, though, is how to transition to such a
> scheme?  Users currently write explicit add-linkers all over the
> place.

Since the choice of link style is an application, as opposed to
library, kind of choice, and the switch is a one-liner, I propose that
we break existing users in a helpful manner.

1) Add support for "deprecated" and "error" attributes to <module>,
<define-linker>, <define-property>, <define-configuration-property>,
<generate-with>, and <replace-with> tags
- This allows messaging to be done up-front, instead of waiting for
the entire link cycle.
- The messages are emitted when the definitions are used with
<add-linker>, <set-property>, or the rebind rule matches
- Library developers also get some benefit in being able to
turn-down existing .gwt.xml "API"
2) Whip up a quick tool to grep .gwt.xml files for the offending
<add-linker> tag and replace it.
- A sed script would be sufficient, although it leaves Windows users
out in the cold.

<define-linker name="xs" class="com.google.PrintErrorAndDieLinker"
error="Replace <add-linker name='xs' /> with <set-property
name='linker' value='xs' />" />

--
Bob Vawter
Google Web Toolkit Team

[Lex Spoon]

On Tue, Dec 22, 2009 at 2:58 PM, BobV <bo...@google.com> wrote:
>> The main question I have, though, is how to transition to such a
>> scheme?  Users currently write explicit add-linkers all over the
>> place.
>
> Since the choice of link style is an application, as opposed to
> library, kind of choice, and the switch is a one-liner, I propose that
> we break existing users in a helpful manner.

Ray Cromwell and I just talked about this, and it looks like legacy
code should not be broken with the changes immediately foreseen.
Legacy users would have a raw add-linker, but that's all they'll need
so long as they don't use runAsync. So it looks like it's just a
matter of emitting good deprecation messages.

> 1) Add support for "deprecated" and "error" attributes to <module>,
> <define-linker>, <define-property>, <define-configuration-property>,
> <generate-with>, and <replace-with> tags
>  - This allows messaging to be done up-front, instead of waiting for
> the entire link cycle.
>  - The messages are emitted when the definitions are used with
> <add-linker>, <set-property>, or the rebind rule matches
>  - Library developers also get some benefit in being able to
> turn-down existing .gwt.xml "API"

Hmm, I see only two things we want users to change:

1.Set the "linker" property rather than using add-linker, for primary linkers.
2. If you define a new primary linker, set up a way for users to use
it via "linker".

Given this, a single deprecation looks like enough: check for the use
of add-linker that (a) has no conditions in it, and (b) adds a primary
linker.

Do you see a need for more deprecation? If that's all it is, then it
seems reasonable to hard code the specific deprecations in the
compiler rather than adding a general deprecation system for module
components.

Lex

[BobV]

> Do you see a need for more deprecation?  If that's all it is, then it
> seems reasonable to hard code the specific deprecations in the
> compiler rather than adding a general deprecation system for module
> components.

It would be a nice-to-have. RayC's impending change to enable
stack-stripping effectively deprecates the "compiler.emulatedStack"
property. Similarly, there are some ClientBundle properties which are
still defined, but that are unused. The change should be pretty much
confined to BodySchema and ModuleDef.normalize().

Otherwise, the two items from your previous email SGTM.

[Bruce Johnson]

Lex/Bob: To clarify one thing, did you mean 

<set-configuration-property>

vs. 

<set-property>

in the example of adding a linker conditionally? I think the latter is what we'd want, right?

I agree it sounds like a nice, unifying change. In the process of cleaning all this up (e.g. deprecation, errors for invalid combos) we really need to bite the bullet and actually specify what the real API-level deferred binding properties are -- the ones people should mention in books and articles -- versus the ones we just use for intermediate values in an ad hoc manner with the expectation of changing them at will.

Related future discussion: I'm not really a fan of <set-configuration-property> and would love to see it go away since in principle it unifies with <set-property> (doesn't it?) All this stuff it getting too fragmented and confusing.

[John Tamplin]

On Tue, Dec 22, 2009 at 10:09 PM, Bruce Johnson <br...@google.com> wrote:

Related future discussion: I'm not really a fan of <set-configuration-property> and would love to see it go away since in principle it unifies with <set-property> (doesn't it?) All this stuff it getting too fragmented and confusing.

The fundamental difference is that a config property may:

• have values which are not valid Java identifiers
• have values not known ahead of time, such as a filename
• have multiple values
• do not impact the set of permutations compiled

What did you have in mind to unify that with deferred binding properties? 

[Bruce Johnson]

Let's take this to a separate thread or a wave, just to keep things organized.

2009/12/22 John Tamplin <j...@google.com>

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors