What's the reasoning for preferring deferred binding properties? I would think that a option to disable sharding globally is more appropriate as a compiler flag than as a module property. My thinking is that since a module encapsulates functionality, it should avoid causing global program changes, such as disabling sharding in other modules.
I understand that linkers, which are configured as module properties, affect global program changes, but I'm not sure that is sufficient reason for further breaking encapsulation. Will adding this as a module property make it more difficult to drop XML module files in favor of annotations in the future? Regards, Sam On Tue, Dec 16, 2008 at 3:09 PM, Lex Spoon <sp...@google.com> wrote: > > On Mon, Dec 15, 2008 at 4:09 AM, BobV <b...@google.com> wrote: > > I was trying to demonstrate the practical difference that runAsync > > would make when compared to a monolithic deployment to someone today, > > and there was no simple way to turn off runAsync that wasn't the > > -disableAggressiveOptimizations flag. > > > > This patch adds an undocumented flag -disableRunAsync that just > > disables code-splitting when compiling an app. > > FWIW, the *implementation* LGTM. The open question is about whether > to keep it as a command-line option or go to a module-file solution. > > > Lex > > > > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
