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 -~----------~----~----~----~------~----~------~--~---
