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
