[OpenLayers-Dev] Re: v3 branch on GitHub for deprecation & API changes

[Xavier Mamano (jorix)]

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 <p.scadden at .cri>
>> 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
>> Dev at .osgeo
>> http://lists.osgeo.org/mailman/listinfo/openlayers-dev
>> 
>> _______________________________________________
>> Dev mailing list
>> Dev at .osgeo
>> http://lists.osgeo.org/mailman/listinfo/openlayers-dev
> 
> 
> _______________________________________________
> Dev mailing list
> Dev at .osgeo
> 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.