Lex/Bob: To clarify one thing, did you mean <set-configuration-property>
vs. <set-property> in the example of adding a linker conditionally? I think the latter is what we'd want, right? I agree it sounds like a nice, unifying change. In the process of cleaning all this up (e.g. deprecation, errors for invalid combos) we really need to bite the bullet and actually specify what the real API-level deferred binding properties are -- the ones people should mention in books and articles -- versus the ones we just use for intermediate values in an ad hoc manner with the expectation of changing them at will. Related future discussion: I'm not really a fan of <set-configuration-property> and would love to see it go away since in principle it unifies with <set-property> (doesn't it?) All this stuff it getting too fragmented and confusing. On Tue, Dec 22, 2009 at 4:17 PM, BobV <[email protected]> wrote: > > 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. > > It would be a nice-to-have. RayC's impending change to enable > stack-stripping effectively deprecates the "compiler.emulatedStack" > property. Similarly, there are some ClientBundle properties which are > still defined, but that are unused. The change should be pretty much > confined to BodySchema and ModuleDef.normalize(). > > Otherwise, the two items from your previous email SGTM. > > -- > Bob Vawter > Google Web Toolkit Team > -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
