Hi, I do believe you are referring to this post:
http://osgeo-org.1803224.n2.nabble.com/Advanced-Closure-Compiler-for-OpenLayers-lite-cfg-46-kb-tc5931700.html but I think it's better to forget ADVANCED_OPTIMIZATIONS (if anyone is interested I can explain why) But can be make advanced use of the Closure Compiler using SIMPLE_OPTIMIZATIONS, there is much to do (check: undefined vars, types, call arguments ...) Now OL only does very basic use of the compiler. A year ago I was researching the use of Closure Compiler in OL: when "--warning_level VERVOSE" gets an endless list of warnings. There is a long way to go to only show those that affect the quality of code, such things as: ../lib/OpenLayers/Control/OverviewMap.js:501: WARNING - Function parseInt: called with 1 argument(s) There is no problem in doing this work in 2.x as it may be gradual. No need to wait for V3. But detect undefined vars only requires build.py + merge.py adjustments, this can be done now. And the use of NaturalDocs as JsDoc is also an issue solved. Xavier Mamano Paul Spencer wrote: > > Advanced compilation adds type hinting/checking which can be useful as a > smoke test when compiling. It is laborious to implement the required > comments to indicate types to the compiler, but once its in place it is > pretty easy to continue using. It also adds some very complex rules for > code optimization and variable replacements - my experience is that it can > be very tricky to work with when converting existing code. I do not > believe that it adds dynamic code loading, it might be work investigating > require.js or some other commonjs module system. > > I believe that closure has some code-quality checks, not sure if they are > equivalent to JSHint or JSLint. I think it is a great idea to include, > though. > > Someone did some work converting a minimal set of code to work with the > advanced compiler a while ago, that's probably in the list archives > somewhere if we want to take a look at it. I think if we want to go this > route, starting with the v3 overhaul is a great place because we can > basically start from scratch and ensure that the API as a whole works with > the advanced compilation settings from the beginning and add new stuff > incrementally rather than starting with the extremely daunting task of > reworking the entire existing code base. > > Cheers > > Paul > > On 2011-11-07, at 11:05 AM, Tom MacWright wrote: > >> I think it's worth a shot, though I'm kind of a newcomer to closure >> compiler - spending most time with uglify-js. I'd assume that the main >> benefit of advanced mode might be some kind of dynamic code-loading / >> externals concept? For code-quality, maybe we should take a look at >> JSHint or similar, as well? >> >> On Sun, Nov 6, 2011 at 3:33 PM, Phil Scadden <[email protected]> >> wrote: >> My 0.0002c. Should v3 be aimed at being usable with advanced compilation >> with the google closure compiler as well? >> >> Notice: This email and any attachments are confidential. If received in >> error please destroy and immediately notify us. Do not copy or disclose >> the contents. >> >> _______________________________________________ >> Dev mailing list >> [email protected] >> http://lists.osgeo.org/mailman/listinfo/openlayers-dev >> >> _______________________________________________ >> Dev mailing list >> [email protected] >> http://lists.osgeo.org/mailman/listinfo/openlayers-dev > > > _______________________________________________ > Dev mailing list > [email protected] > http://lists.osgeo.org/mailman/listinfo/openlayers-dev > -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/v3-branch-on-GitHub-for-deprecation-API-changes-tp6959931p6975094.html Sent from the OpenLayers Dev mailing list archive at Nabble.com. _______________________________________________ Dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/openlayers-dev
