Great. I will consider you folks, per the norm, to be on top of it. :-) Thanks, -Noah
On Mar 8, 2011, at 12:38 PM, Antranig Basman wrote: > Hi Noah - thanks for the pointer - we had indeed noted the existence of > jshint - it looks like a great direction and ultimate repository for these > changes but so far hadn't done anything about it simply because of lack of > understanding of proper "git mechanics" - since jshint isn't actually a > "fork" but actually a completely separate cloned and renamed development of > jslint, branches and commits can't be shared directly between the projects. > Right now jslint's fork cloud still has greater activity than jshint and so > it seems reasonable to "wait and see" how the various community dynamics sort > themselves out over the next few months. > Secondly, there are a few "Fluid-specific" parts of the UI in particular that > I'm not clear how we could maintain as a "privately tracked" set of changes - > that is, something version-managed but not something that all users get as > default. This is probably possible with git but I'm not sure how. If jslint > were itself based more heavily on Fluidic technologies, rather than > Crockford's rather brittle DOM manipulation library, this would be also > easier to see how to do in the app itself rather than through VCS - but at > the moment, either path looks like a moderately hard one to set up in such a > way that it is low-maintenance for all users. > Certainly once our ideas about what linting features we want and also our > implementation stabilises, harmonising our implementation with a version > tracked and used in the wider community is an attractive one. Linting, of > course, so often degenerates into a form of "bikeshed painting" :) > > On 08/03/2011 10:15, Noah Botimer wrote: >> Sounds like quite an accomplishment. It may be irrelevant at this point, but >> you may like to check out http://jshint.com/. Perhaps you or they would be >> interested in each other's work. >> >> Code quality cheers! >> >> Thanks, >> -Noah >> >> On Mar 8, 2011, at 12:04 PM, Antranig Basman wrote: >> >>> I have placed a revised version of the implementation of the JSLint tool >>> that we have inherited from Douglas Crockford up at >>> http://ponder.org.uk/fluid/fulljslint.html - the source code is also >>> available for inspection in my github area. >>> Since we have established that no economies of development are possible by >>> sharing even the most conservative fixes upstream, I've taken the >>> opportunity to overhaul the implementation thoroughly, and have fixed >>> several bugs relating to outright misparses as well as misinterpretation of >>> wrapping constructs, as will as implementing some new options and >>> configuration to make it easier for our project to use. I am surfacing a >>> list of what some of these are (in cases where there might be different >>> opinions) so that we can decide now we have a free hand what kinds of code >>> we want to tolerate. Please also speak up if you have any suggestions for >>> completely new features of JSLint that are not in this set, since our >>> implementation is now our own and it has been found fairly straightforward >>> to implement new features. >>> >>> Firstly, the reason for the original fork in the first place, an option to >>> tolerate the for (var x in ...) construction which recent versions of >>> JSLint threw out as an unconditional parse error, aborting further >>> processing. (forvar) >>> >>> Secondly, an option to tolerate two variants for block indentation of >>> "run-on" control structures, being if...else and try..catch..finally - >>> original JSLint would ONLY tolerate the following variant >>> if (cond) { >>> material 1; >>> } else if { >>> material 2; >>> } >>> whereas we may now tolerate BOTH the above variant and ALSO the following >>> (I believe more commonly seen) form (elsecatch) >>> if (cond) { >>> material 1; >>> } >>> else if { >>> material 2; >>> } >>> >>> Thirdly, an option to tolerate zero or one spaces in a few cases around >>> operators - the vast majority remain at the original defaults of requiring >>> exactly 1 space for binary operators (&&, ===, etc.) and zero spaces for >>> unary operators (++, --) but at least in my opinion, our rules for spaces >>> following the "function" keyword have been annoyingly inconsistent, with >>> exactly zero spaces tolerated in one case and exactly one space tolerated >>> in another. With the option (operator), either zero or one space are >>> tolerated - for example, both >>> var x = function (x) {.... >>> and >>> var x = function(x) {... >>> are acceptable. >>> >>> The indentation rules in general are unchanged in this implementation, >>> apart from a few bug fixes in cases of multiple constructs per line which >>> would sometimes lead to original JSLint to recommend NO indentation on the >>> next, multiply nested line which was clearly a bug (constructions like >>> var y = fluid.transform(list, function(value, key) { >>> ... would often require faulty indenting HERE. ) >>> >>> Fourthly, there is a new "emergency escape" rule in the form of a specially >>> formatted comment accepted on a line (this is a common option with the >>> implementations of linting tools in the C world from which JSLint takes >>> heritage) - of the form // jslint:ok - this allows a one-off override of >>> the linting rules for a particular line of code that has been determined >>> through specific inspection to be safe. Clearly this rule must be used very >>> sparingly since most linting violations (especially in the new >>> implementation) are genuine. It was used a few times in the renderer code, >>> particularly to allow exceptions for the "var x is already defined" warning >>> caused by JavaScript's anomalous scoping rules, and for the "do not declare >>> functions in a loop" rule which is a blanket recommendation which JSLint >>> makes without any inspection of the flow involved. In particular, functions >>> which do not bind to the loop counter variable for the loop they are nested >>> in should be excepted from thi > s rule. Lots of the renderer code is quite intricate and allowing a handful > of violations (in my opinion) allowed the code to remain more readable by not > having to arbitrarily rename some variables which clearly served the same > function, or reduce locality by breaking small anonymous functions out of > loops. >>> >>> Please chime in with your opinions on what you think we should do about >>> these various options and constructions :) >>> >>> Antranig. >>> _______________________________________________________ >>> fluid-work mailing list - [email protected] >>> To unsubscribe, change settings or access archives, >>> see http://fluidproject.org/mailman/listinfo/fluid-work >>> >>> >> > > > _______________________________________________________ fluid-work mailing list - [email protected] To unsubscribe, change settings or access archives, see http://fluidproject.org/mailman/listinfo/fluid-work
