Hi Martin - your careful review is much needed :-) ReferencedEnvelope was introduced a long long time ago; it used to be an inner class of JTS. I admit that email discussion was brief at the time. The only other Hack I know of this nature (where a compromise was made quickly so work could be done) is TypeName
I do hope that this new procedure for introducing API change can be used to scare up useful discussion/review before changes like this are made. Cheers, Jody > My opinion may be biased because I'm a very slow guy and maybe too > perfectionist, but maybe the geotools stability problem is caused at least > partially by code commited too fast without suffisient effort for making it > future proof. Example: > > org.geotools.geometry.jts.ReferencedEnvelope > -------------------------------------------- > I noticed today that a bunch of new methods were added 2 months and half ago. > My > observations: > > * The new methods have no javadoc at all. Please, remember to write > javadoc at least for every public API, with a @since 2.4 javadoc tag. > > * Those new methods violate the contract of the interface they > implement. The BoundingBox contract said "minX: This is a helper > method for getMinimum getMinimum(i) where i is the ordinate used > to represent easting", but the minX() implementation invoke JTS's > getMinX() method inconditionnaly without any regards to the > underlying CoordinateReferenceSystem axis. > > I'm in the process of adding javadoc for those new methods, with a @todo tag > saying that we may have a contract violation problem there. In the future, we > will need to either change the contract, or change the implementation. The > later > may be the kind of compatibility break that hurt Geotools. > > (actually in this particular case I believe that the implementation is correct > and the contract need to be changed, but this is an other topic). > > Maybe we should push for more discipline with the following: > > * Take more time in order to think very hard: "is my implementation doing > the right thing"? Thinking harder take more time, but it may have the > interresting side effect of letting more time for other developers to > review code. > > * Javadoc always. It take time but may have the interresting side effect > of letting more time for other developers to review code. > > * If we don't have the time to implement an API fully right from the > begining, this is okay but check if the conditions are meet (e.g. > in the above 'minX' method, if we don't have the time to implement > a search method for the right axis, thrown an exception if the first > axis direction is not NORTH). It take time but may have (... etc ...). > > Martin > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Geotools-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geotools-devel > ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
