This is certainly a welcome improvement, I detailed a similar issue last year (http://groups.google.com/group/Google-Web-Toolkit-Contributors/msg/0422bc6f44e950a9) in which I needed to run accumulate data (in this instance, a bunch of mappings), and then generate another class that uses this information. It seems that this proposal solves the user case of needing a shared variable, but it doesn't solve the ordering issue, so it's still impossible to guarantee a pre-pass or post-pass. It's unclear that this can even be done by explicitly in code (e.g. GWT.create(PostPass.class) since there is no guarantee that GWT can't reorder GWT.create() calls out of lexical order)
Some of the things I'd like to do involve using one Generator to gather information from a bunch of classes, and then using another (possibly with explicit instantiation in source) to take that information and generate another summary class from it. I don't know if it's really possible to do. Part of the difficulty arises because I'd like to run the Generator *after pruning*, otherwise the "post-pass" generator might prevent some classes from getting pruned. Ah well. -Ray On Tue, Sep 9, 2008 at 2:09 PM, BobV <[EMAIL PROTECTED]> wrote: > > Working on CssResource has shown a limitation in the Generator model > in that there are no provisions to accumulate state between > invocations of a Generator while rebinding a module. The general > problem with assuming stateful Generators is that the lifecycle and > invocation order of Generators are intentionally undefined. > > There is a class of problems (such as counting or name-assignment) > for which it is useful to be able to use accumulated state to reduce > the amount of work an individual invocation must do. In the specific > case of CssResource, I want to assign each class accessor function to > a unique, obfuscated name. This requires either a total ordering of > all accessor functions or knowledge of previously-allocated names. > > Instance fields are insufficient: > - The lifecycle of a Generator is not well-specified. > > Static fields are insufficient: > - Due to the unspecified lifecycle of a Generator, it is possible > that one invocation of the JVM might be used to compile multiple > modules. > - Public, static fields could encourage a programming style that is > fundamentally brittle if developers make assumptions about relative > ordering. > > Proposed solution: > - Add get/setUserObject() methods to GeneratorContext. > - Within the lifetime of a single compilation, this will be backed > by a Map<Class<? extends Generator>, Object>. > - No particular lifecycle is assumed for the Generator and no state > can be transferred between Generator types. > > Questions: > - Should we require that the user-object implement (Java) > Serializable? This would allow us to use a weak Map and unload the > object from memory until it's needed again. > > -- > Bob Vawter > Google Web Toolkit Team > > > > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
