Hei Landon, a few comments on your changes [personal thoughts]
> However, I think there is a reasonable solution: > > I'll keep all of my changes in my own fork. I'll regularly present > these changes to the OpenJUMP programming community. I'll clearly > identify those changes that I think are necessary to avoid bugs to to > enable a critical new function in the program. this is good > This type of change > will be distinguished from changes which are cosmetic or very minor. > Then we can let the changes be approved and adopted by the group on > there own merit. (I'll try not to get my feelings hurt when something > doesn't get in.) :] that is better :) > > Let's look at my TaskFrame/Workbench Context changes as an example: > > Critical Changes: > > Call CursorTool.cancelGesture method when closing a TaskFrame. I know you may have pointed out why you did that, but why would you do that? What happens then? The mouse pointer changes? > Remove TaskFrame.setTask method and modify > WorkbenchContext.addTaskFrame method to no longer use > ComponentFactory. What was the reason for this change? to avoid the use of the component Factory? Here I would leave the factory as I would assume that there is a reason why they used that. To remove a method sounds dangerous to me (usually one starts with introducing a depricated label.. but as it is your personel edition) > > Cosmetic Changes: > > Group all public, protected, and private methods together in class file. this makes things messy in a repository in terms of tracing and comparing old and new code. so I would avoid that in general for released code. > Implement InternalFrameListener instead of using hidden > InternalFrameAdapter class. not sure about this. It sounds logic from my side. And as it is hidden it would not break any access method. So from my "non-programmers" perspective I would go with that change. > Add isAClone member variable, setIsAClone public method. Adding something is ok. But you should outline why do you add this? > Add Javadoc comments for all public methods. this is always! appreciated :) > Would we be interested in any of the cosmetic changes? my 2 cents: in general no cosemtic changes on old code if it is not necessary to make things work or fix a bug. The only exception to is javadoc. We need this as there are (unfortunately) only a few wizards in our group (Paul, Martin, Andreas, ...). > > I want to point out that if we take a more assertive stance on unit > testing JUMP cosmetic changes to the core would be less of a > risk...Maybe I'll start working on some unit tasks for key classes in > the core. if you want and can write tests then go ahead with this (However, for the stuff I programm, i.e. data analysis, I feel it is almost impossible to use unit tests... but I have also never programmed them) ------------------------------------------------------------------------- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
