2009/9/11 <[email protected]>: > > Also: > > First of all: I honestly don't have a clearly defined conclusion yet > since (fwiw...) I think the overall documentation scheme espoused by > this CL is actually pretty nifty. > > One other way to look at it might be to think about what is special in > the Caja project that we could provide as unique value (beyond other > joe generic doc tools that might exist). Does our work encourage (or > require) a style of programming (with closures rather than prototypal > inheritance and Java-like "classes") that in turn requires this tool? > If so, is this tool generally useful for the world, or is it only > useful for Caja? If for Caja, should we optimize it as a doc tool *for > cajoleable code*? What, if any, simplifications do we gain by > narrowing the focus as such? If not just for cajoleable code, do we > best serve its purpose by making it a completely separate project? > > One thing to think about is that, hopefully, our TCB of un-cajoled > code should remain small and get smaller. Hence maybe we get a bigger > win for something that cajoles Caja code (and, say, appends docs to > the module format in much the same way that the debug information is > currently added). > > In any case, here's some data. After patching in this CL: > > .../google-caja ihab$ svn diff | wc -l > 9989
Sure. If you include tests, documentation, unchanged context lines, and whitespace lines; and double-count changed lines you get a big number. If you count only operational lines of code, it's 4012 LOC. > > That's 10kloc for a documentation tool used as part of our build > process. In addition to the benefits of such a tool, we should be > worrying about cost. > > Ihab > > -- > Ihab A.B. Awad, Palo Alto, CA >
