RE: [jdt-ui-dev] Refactoring: Any plans for a Lint like tool (...a tool

["Scott Stanchfield" <scott@xxxxxxxxxxxx>]

Ahhh... seems I missed the connection to providing refactorings. Iwas just
thinking about the lint-like reporting aspect.

-- Scott

====================
Scott Stanchfield
FGM, Inc.
scotts@xxxxxxx
====================

> -----Original Message-----
> From: jdt-ui-dev-admin@xxxxxxxxxxx
> [mailto:jdt-ui-dev-admin@xxxxxxxxxxx]On Behalf Of Valentino Kyriakides
> Sent: Wednesday, December 04, 2002 12:22 PM
> To: jdt-ui-dev@xxxxxxxxxxx
> Subject: AW: [jdt-ui-dev] Refactoring: Any plans for a Lint like tool
> (...a tool to identify bad code smells...)?
>
>
> > -----Ursprüngliche Nachricht-----
> > Von: jdt-ui-dev-admin@xxxxxxxxxxx
> > [mailto:jdt-ui-dev-admin@xxxxxxxxxxx]Im Auftrag von Scott Stanchfield
> > Gesendet: Mittwoch, 4. Dezember 2002 15:20
> > An: jdt-ui-dev@xxxxxxxxxxx
> > Betreff: RE: [jdt-ui-dev] Refactoring: Any plans for a Lint like tool
> > (...a tool to identify bad code smells...)?
> >
> >
> > There's nothing wrong with using ANTLR for a tool like this ;)
>
> Well, I didn't meant generally that is a wrong idea by using
> ANTLR or JavaCC
> etc. It depends IMO on several points and what you intend to support:
>
> - If it is hard to determine how an IDEs refactoring API works at all, or
> such an API isn't documented, then using ANTLR/JavaCC might be the better
> way to reach the aim.
>
> - If you have to be portable between different IDEs or you want to support
> different IDEs with an own build refactoring tool etc. you sure better use
> ANTLR/JavaCC here, since every IDE uses different underlayed parser
> architecture concepts here.
>
> But if you just want to enhance some specific primary IDEs refactorings
> here, why shouldn't you reuse it's main build in capabilities
> here? I mean,
> where Eclipse has already build in support for incremental code
> parsing, AST
> caching and searching etc. why should one rebuild all this say
> via ANTLR, if
> he just want's to do all this mainly for Eclipse and none of the
> other IDEs
> around.
>
> BTW, in the past I've used ANTLR a lot for such purposes, mainly
> for an own
> JBuilder integrated refactoring tool and some other code
> restructuring/manipulation tools. However, in the mean time
> Borland has most
> of this build in themselves into their IDE and thus my past old tools have
> got somehow obsolet now.
>
>
> > (I used to work for Terence Parr, its creator, and I'm looking at
> > porting my
> > ANTLR debugger, ParseView, to Eclipse at some point ;)
>
> I know that ParseView (well, possibly an older version of it). I've once
> used it for debugging an ANTLR crossreference tool I had
> developed. But this
> is now some time ago. - Last time I looked at ANTLR, there wasn't any
> suitable ParseView version available for it, so you must have
> upgraded this
> one in the mean time.
>
> > Sure, someone could write a tool that uses the Java AST support
> > in Eclipse,
> > but then that tool would only be useful inside Eclipse.
>
> Yes, exactly, see my above points!
>
> > Some fo the tools
> > like this I've seen (javacheck, for example, and the auditing tools in
> > Instantiations' CodePro Studio) target other environments, and
> > decide to use
> > other tools like ANTLR.
>
> AFAIK, Instantiations CodePro uses ANTLR for the refactoring
> part, at least
> they did so in the past, when they offered IBM VAJ and JBuilder supporting
> versions of their tools. I don't know what they actually use
> internally, but
> I believe it will still be ANTLR based, since they invested some time to
> develop this.
>
> > Of course, one could make the argument that Eclipse reinvents several
> > wheels. Even so, where's the inherent harm?
>
> Yes, this always depends on, from which side you look at it. As a coin has
> two sides, this also applies to this theme.
>
>
> -Valentino
>
> _______________________________________________
> jdt-ui-dev mailing list
> jdt-ui-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/jdt-ui-dev