Good thoughts, Ray. The only way to guarantee order is to have a generator emit a GWT.create() call. Your other thought about post-pass generation is something Bob's done a lot of thinking about. Have you read Bob's new proposals on RPC? They include reference to apis for computing reachability.
On Tue, Sep 9, 2008 at 6:00 PM, Ray Cromwell <[EMAIL PROTECTED]> wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
