Stefan Breunig wrote: > If classes need fixing, why not just add a new one > "classThatNeedsFixing2" with a proper implementation. Change JOSM to > use "2" in various places, let it bake and see if it needs any > additional feature and mark the old class as depricated and advise > develops to use "2" instead. That way all new devs will likely use "2" > and some other references to the old code will be changed as well.
This leads to two different implementations that have to be maintained as long as version n+1 has not replaced version n - not a desirable state from my point of view. IMHO Java already contains the perfect feature for step-by-step code-evolution: @Deprecate annotations/javadoc comments - see here for details: http://java.sun.com/j2se/1.5.0/docs/guide/javadoc/deprecation/deprecation.html You can mark fields and methods as "deprecated" so that other developers see (compiler warning) that this element is subject to be changed to private/deletion but it is still usable and old code works without modification. GeoJ _______________________________________________ josm-dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/josm-dev
