Just to chime in with something that might be obvious... - minx,miny,maxx,maxy was standard to me until I started using JTS, then minx,maxx,miny,maxy had to become "standard". - rectangles often use minx,miny,width,height which's annoying too - I see no _real_ reason to change the argument ordering, you always should read what the arguments are for before using an api anyways - If still uncomfortable with the current ordering, wouldn't it be safer to deprecate it and replace by DirectPosition2D lowerCorner,DirectPosition2D upperCorner, or such?
2cnts. Gabriel. On Monday 04 February 2008 08:13:04 pm Martin Desruisseaux wrote: > Jody Garnett a écrit : > > That sounds like a really scary change; all client code would still > > compile but be wrong? > > Yes, thats the problem. The best we can do is to produce a deprecation > warning on 2.4. > > > So here is a suggestion - making the constructor package visible (so > > client code will break) and using a geometry factory? > > Actually it is not geometry but metadata > (org.geotools.metadata.iso.extent.GeographicExtentImpl). We don't have a > factory for metadata yet. It would be a significant work to create one > because: 1) there is about 100 metadata interfaces and 2) there is no > setter in interfaces at this time, which would make the factory very > complex if we must provide everything as constructor argument (unless we > use a java.util.Map, but this is not type-safe). > > I have no objection to remove the public visibility on 2.4 branch - the > easier workaround is to use the constructor expecting a Rectangle2D > argument. > > > You are correct that argument order for bounds / rectangle / bounding > > box and such like is very annoying. It is one of the mistakes that every > > geotools user makes when learning. > > Thats why I worry about aligning this constructor with what seems the most > common usage... > > > Making a method that acccepted raw doubles may not be worth it; no > > performance gain and it is ambigious... > > Yes this is a very strong argument... The rational was not performance but > convenience, and the ambiguity may be mitigated if we align with common > practice. But I admit that it still unsafe. > > Martin > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Geotools-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geotools-devel > > !DSPAM:4045,47a763d8101455409313003! ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
