I think that what lukas wanted to say is that it is difficult to produce good tools, to maintain them over a long period of time and that it is often more interesting to stack up effort to make sure that at the end we get something. This is why having more rules under SmallLint is interesting.
Now why should we use Sawlint when we have smallLint. What is your selling arg? Because so far this is not clear.
Stef
On May 26, 2008, at 9:01 AM, Tobias Pape wrote:
Hello Sophie,
Am 2008-05-25 um 16:54 schrieb itsme213:
"Tobias Pape" Das.Linux@gmx.de wrote in message news:937EDCAE-2C7E-42B9-90CD-CDDFA4BB31D3@gmx.de...
Actually, we believe that it is a great programming aid facility for a developer. But using it showed that there are several problems. One example would be the UI. What we wanted to say is that using the supplied Tool window can be very confusing.
I discovered Lukas' tool set (not just SmallLint, but also the scoped environment browser, AST-based search, replace, re-factor, etc.) recently. It is such a *huge* improvement, that I would urge you to contribute towards improving that stream rather than fork a different one.
I want to place an emphasis on the fact that SwaLint is no fork off SmallLint. Its architectural codebase is not based on it in any way. Moreover, SwaLint is capable of using every test provided by SmallLint, thus, I hope SwaLint will also benefit from SmallLint improvements. For the environments i wanted to say that the notion of scoping is slightly different in SwaLint. And, well, some plug-ins in SwaLint are using AST-based searches as well.
To share my Personal opinion, I don’t think it is necessary to incorporate refac- toring or any other code-changing into code critics tools. I appreciate the fact that SmallLint is capable of it, but for SwaLint we’d like to follow the “do one thing and do it right” approach as best we are able to.
Have a nice week. So long, -Tobias