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

Tom MacWright tom at macwright.org
Sun Nov 20 22:21:24 EST 2011


Hey,

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?

Tom

On Tue, Nov 8, 2011 at 12:12 PM, Xavier Mamano (jorix) <
xavier.mamano at gmail.com> wrote:

> 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 &lt;p.scadden at .cri&gt;
> >> 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.
> _______________________________________________
> Dev mailing list
> Dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/openlayers-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/openlayers-dev/attachments/20111120/d7e4e10a/attachment.html


More information about the Dev mailing list