Hi Andrew, > -----Original Message----- > From: Andrew Hyatt [mailto:[EMAIL PROTECTED] > Sent: Wednesday, September 03, 2003 5:00 PM > To: Abousalh-Neto, Nascif [NCRTP:3X20:EXCH] > Cc: [EMAIL PROTECTED] > Subject: Re: Refactoring with JDE? > > > "Nascif Abousalh-Neto" <[EMAIL PROTECTED]> writes: > > > Hi Andrew, > > > > Hmm, I have to disagree here. First I don't think you can beat a > > refactoring editor in terms of speed if you take into account > > propagating the changes to > > all affected modules, specially in a medium-large project > (think rename > > method, or even rename variable for a protected variable > used by many > > subclasses). Since emacs is all about speed, it makes sense to use a > > specialized tool rather than macros and other tricks if one is > > available. > > For things that need to know caller locations, true. But > jde-xref already handles that info, it could be extended to > some of those refactorings. But many of the common
Good point. What do you think should be the way to go with support for refactorings in JDE? I can see three major directions: 1) Expanding on the jde-xref functionality 2) Using the new semantic 2.0 - assuming it has all the necessary functionality 3) Use a Java-based backend or C-based, like Transmogrify or xrefactory. I think that using an approach similar to the JDE compile server, which keeps an instance of the java compiler running at all times, the Java approach may be feasible in terms of performance. Then again I don't know how Lisp-based grammars compare in terms of speed and memory usage with Java-based ones. > refactorings such as "extract method", "pull up method", etc, > are easy to do by hand. For the "extract method" refactoring, consider a block of code that uses local variables. You have to create for each instance of a local variable an equivalent method parameter, and fill the method call with the associated arguments. And so on. A true refactoring tool is very much like a calculator; sure you can make basic calculations by hand and most of the time it is faster this way, but besides the trivial cases you always use the calculator not only for speed, but also so that you don't worry if any of the intermediate steps in your 5-digit multiplication was wrong and can "trust" the result - OK, maybe I am bad in math... :-) > The problem with the more advanced IDE's is that they are > SLOW. Eclipse is supposed to me much faster then JBuilder, > and Eclipse is just a dog compared to emacs. Eclipse makes > doing advanced things easy, and by doing this they slow down > normal editing. Personally, I prefer a fast editor above all > else. (Yes, I know you can turn off certain features in > Eclipse to speed things up, but this eliminates many of the > good features of Eclipse). > > Perhaps there is a way for us to have our cake and eat it > too. But I for one haven't thought of how. Agreed. I also choose speed over bells and whistles hands down. But given Emacs power I think it may be possible to have both; it may be more a matter of finding the right balance between speed and functionality. Regards, /Nascif > > > > I have been thinking about it as well. I agree it would > require a lot > > of JDE changes to make things more consistent, but is that > necessarily > > a bad thing? > > I don't see why JDE would lose flexibility, and actually I think it > > would have two benefits: > > 1) It could make JDE more efficient by doing a very core > thing - keeping > > the > > structure of the code in a "usable" format - in exactly one place. > > Granted it is a complex and expensive operatation, which is exactly > > why it should be > > done once and re-used by all other modules. > > 2) It would allow for more powerful extensions/plug-ins > because the hard > > work of gathering semantic info from the code would already > have been > > done; > > designers would only have to learn the API to get them; > > 3) Not only refactorings could be done but all kinds of > operations can > > benefit from a better model of the code. For example, the try-catch > > replacement we have talked about in this list could wrap > the code using > > the > > exact exceptions; searches could filter on exact > characteristics (like > > search method call); and so on. > > It's not the flexibility of JDE I am concerned about, it's > the flexibility of users. It somehow feels wrong if JDE > would require a lock-in in the same way Eclipse (and probably > other JDE's do). I agree with you to an extent about the > usefulness of centralizing semantic info, but I'm not sure it > should be done ahead of time. If it could be done as needed > it might be better. > > > > > Regards, > > /Nascif > > > >
