> Martin Fowler suggests that refactorings should be performed in a small > steps, and IMHO this is the right way to perform them.
Well, conceiving of refactorings as small steps or bricks is certainly the correct design approach. However, it seems limiting if that is as far as you are willing to go. The whole point of programming in general is to isolate small steps and concatenate them into larger ideas that can then be reused en masse. I suppose an open API will allow me to resolve these issues for myself anyway. Kirk >-----Original Message----- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On >Behalf Of Eugene Zhuravlev >Sent: Friday, November 09, 2001 2:06 AM >To: [EMAIL PROTECTED] >Subject: Re: [Eap-list] Refactoring inner classes to outer > >> Yes, I know, but then it just involves so many more CVS operations that >> it seems clunky. Specifying the destination of the operation seems like >> a natural desire. > >In this case you can just escape the appeared dialog (do not add to CVS), >move the class and confirm the CVS add dialog suggesting to add your class >to the destination package. BTW, in the future versions we are planning to >rework our CVS integration. >Moving an inner class to any package will complicate the dialog and >refactoring itself, because you will need to think about other issues such >as class accessibility from the target package. Why do the job that another >refactoring does best? It is always better to have a small set of >refactorings each doing its job quickly and efficiently (simple dialogs >with >not too much options to check are also important IMHO). Using these tools >as >a "bricks" you can easily perform more complicated refactorings. Martin >Fowler suggests that refactorings should be performed in a small steps, and >IMHO this is the right way to perform them. > >> You are right, but since a dialog is popping up anyway it seems like a >> trivial task to add a couple of extra options. That way it could >> remember what you last did, saving time on repetitive tasks. > >It is possible to agree here. Perhaps we will add possibility to change >class' access modifiers in the dialog. > >Best regards, >Eugene Zhuravlev >IntelliJ Software, http://www.intellij.com/ >"Develop with pleasure!" > >----- Original Message ----- >From: "Kirk Woll" <[EMAIL PROTECTED]> >To: <[EMAIL PROTECTED]> >Sent: 08 November, 2001 10:23 PM >Subject: RE: [Eap-list] Refactoring inner classes to outer > > >> >-----Original Message----- >> >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] >> On >> >Behalf Of Eugene Zhuravlev >> >Sent: Thursday, November 08, 2001 10:58 AM >> >To: [EMAIL PROTECTED] >> >Subject: Re: [Eap-list] Refactoring inner classes to outer >> > >> >> Does not allow me to specify the destination. Currently it spits the >> >> class out into the same package that the current class is in, which >> is >> >> not what I want. >> > >> >But you can always move the class with the "Move to" refactoring. >> >> Yes, I know, but then it just involves so many more CVS operations that >> it seems clunky. Specifying the destination of the operation seems like >> a natural desire. >> >> >> Also, it seems to make the new top-level class have >> >> package level access, which is, for me anyway, never what I want. >> > >> >This is done if your class was declared private or package local. The >> class >> >is left public if it was originally declared as public. >> >Anyway you can always easily change the class visibility. >> > >> You are right, but since a dialog is popping up anyway it seems like a >> trivial task to add a couple of extra options. That way it could >> remember what you last did, saving time on repetitive tasks. >> >> Kirk >> >> >> _______________________________________________ >> Eap-list mailing list >> [EMAIL PROTECTED] >> http://www.intellij.com/mailman/listinfo/eap-list > > >_______________________________________________ >Eap-list mailing list >[EMAIL PROTECTED] >http://www.intellij.com/mailman/listinfo/eap-list _______________________________________________ Eap-list mailing list [EMAIL PROTECTED] http://www.intellij.com/mailman/listinfo/eap-list
