On Tue, Dec 22, 2009 at 2:58 PM, BobV <[email protected]> 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 -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
