Very interesting, you argue your case well :) I'll definitely be keeping an eye on it!
On 28 March 2011 18:42, Olov Lassus <olov.las...@gmail.com> wrote: > On Mar 28, 6:54 pm, Nick Morgan <skilldr...@gmail.com> wrote: > >> Ok, that makes sense. I can imagine this being a useful tool, >> especially on large codebases with a lot of developers. Though it >> feels a lot like the whole static typing thing - "it catches all kinds >> of errors", but the kinds of errors that wouldn't be made with good >> tests and code reviews. I dunno. > > Static typing is heavy on your fingers though, unless you use ML or > another type inferencing language. You may find that in contrast to > type annotation (such as via the google closure compiler), restrict > mode doesn't really require much of an effort from you. Chances are > that you'll need to replace a few str + nostr instances and that's it > - your program is now restrict-clean. If you have a function that does > a lot of string mangling and don't want to rewrite it then just / > *@loose*/ annotate that function and you're good - it won't be > restrict-checked. Or vice versa: "use restrict"; on selected > functions, not the entire program. The effort to make your already > well-written program restrict-clean is really small but the benefits > are potentially large. The effort of making a new program restrict- > clean from the minute you start writing it is even lower. Once your > program is restrict-clean, you can choose to run restricter on it as > seldom or as often you want. I think running restricter every time you > execute your unit test suite is the sweet spot, but that's just me. > > Restrict mode catches real defects. Let me give you two examples: > > 1. v8bench-splay spent a lot of time converting strings to numbers. > http://code.google.com/p/v8/issues/detail?id=690 > This defect didn't affect the correctness of the program but > it did slow it down unnecessarily. > > 2. The Kraken audio-fft and audio-beat-detection benchmarks > performed arithmetics on undefined due to uninitialized > variables. https://bugzilla.mozilla.org/show_bug.cgi?id=599914 > This defect affected the correctness of the program. > > In an attempt to see how well the subset defined by restrict mode > matches real, big and well-written programs, I made the jQuery > codebase (src/) restrict-clean. Enough so that their entire test suite > ran without any restrict mode exceptions. I had to modify a couple of > dozen lines of code. > > At the end of the day restrict mode is just another set of guidelines > for how to write better code, and restricter is just another tool to > consider. > > /Olov > > -- > To view archived discussions from the original JSMentors Mailman list: > http://www.mail-archive.com/jsmentors@jsmentors.com/ > > To search via a non-Google archive, visit here: > http://www.mail-archive.com/jsmentors@googlegroups.com/ > > To unsubscribe from this group, send email to > jsmentors+unsubscr...@googlegroups.com > -- Nick Morgan http://skilldrick.co.uk @skilldrick -- To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/jsmentors@jsmentors.com/ To search via a non-Google archive, visit here: http://www.mail-archive.com/jsmentors@googlegroups.com/ To unsubscribe from this group, send email to jsmentors+unsubscr...@googlegroups.com
