I just remembered one trick I think you might get by with until we resolve this question. There's something involving caching a reference to the TypeOracle and doing an identity check on it to determine that you're part of the same compilation. Um, you'd have to check if this is brittle in post-FSOD hosted mode tho. There's also a way to ask TO for a revision number I think.
On Tue, Sep 9, 2008 at 5: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 -~----------~----~----~----~------~----~------~--~---
