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