Larry wrote: "I think we should look at the vividsolutions code base as legacy - to be maintained but not extended much."
I'm OK with that philosphy. It would provide better separation between Vivid's code and code contributed by the community if copyright or other legal issues ever come up. Larry wrote: "What is it about these two methods that doesn't fit this paradigm?" Both of the methods deal with arrays/collections, but are found in different classes. I think it would be better to have a org.openjump.core.util.CollectionUtil class, where all new utility methods dealing with collections could be stored. Ideally, I'd like to see the utility methods packaged in another JAR, so they could be distributed independently of the other JUMP code, but that might be asking for too much. My ultimate goal is to have utility code found in as few places as possible. This will reduce the amount of duplication. I know this thinking rubs against the grain. The consensus of the majority in the past has been to leave things alone so nothing gets broken. I'm going to occassionaly push for some refactoring as I work on my own fork of the code base, but I don't expect any of my changes to be adopted by the group. They are just suggestions. I wouldn't do anything until Stefan had a chance to comment, at any rate. I dream of a leaner and meaner OpenJUMP. :] SS On Wed, Jun 24, 2009 at 1:38 PM, Larry Becker<becker.la...@gmail.com> wrote: > I think we should look at the vividsolutions code base as legacy - to be > maintained but not extended much. New stuff should generally go into > openjump.core. What is it about these two methods that doesn't fit this > paradigm? > > regards, > Larry > > On Wed, Jun 24, 2009 at 2:54 PM, Sunburned Surveyor > <sunburned.surve...@gmail.com> wrote: >> >> There are two (2) methods in the org.openjump.core.apitools that I >> think we should move to the >> com.vividsolutions.jump.util.CollectionUtil class. The first method is >> the org.openjump.core.apitools.CollectionTools.addArrayToList method. >> The second is the >> org.openjump.core.apitools.FeatureCollectionTools.resizeArray method. >> >> I'm willing to make this move in OpenJUMP and ensure it doesn't break >> anything in the core. It will be a little more difficult to ensure >> things don't break in the PIROL plug-ins. >> >> We can certainly leave things the way they are, but I'd really like to >> consolidate some of the utility methods we've got laying all around >> the core. I think this type of maintenance needs to be done at some >> point, or the stink in our code base will only get worse with time. >> >> If someone is willing to help me track down the source code for the >> PIROL plug-ins, I would be willing to refactor them with the change as >> well. >> >> Let me know what you guys think. >> >> SS >> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Jump-pilot-devel mailing list >> Jump-pilot-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > > > > -- > Larry Becker > Integrated Systems Analysts, Inc. > > ------------------------------------------------------------------------------ > > _______________________________________________ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > > ------------------------------------------------------------------------------ _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
