Andrea Aime a écrit :
> Why in the world GeographicBoundingBox.getXXXXBoundLongitude should
> return a Double instead of a primitive, it just makes it harder to use
> and generates more garbage? Having fast garbage collection and
> autoboxing does not seem to me a good excuse to introduce diffuse
> inefficiencies so light heartedly?
I'm still hesitant about this issue. It was debated there:
http://jira.codehaus.org/browse/GEO-103
I see pros and cons on both sides. We try to avoid "magic number" like -1 for
flagging missing values. Using 'Integer' instead of 'int' allows to return
'null' value.
In previous metadata interfaces, the return type was Integer only for optional
attributes and was 'int' for mandatory attributes. Jody pointed out that
invalid
(or incomplete) metadata exists in the wild, so we sometime need to returns
'null' (or thrown an IllegalStateException) even from mandatory attributes. An
other argument is that the obligation state (mandatory vs optional) of some
attributes changed between different ISO 19115 versions. If we don't uniformize
the API with Integer in all cases, future obligation change would imply a
compatibility break in future GeoAPI interfaces.
The above points sound good to me at least for integer types (while I may have
preferred IllegalStateException rather than null values for missing mandatory
attributes - but I'm not sure about that neither). However I'm more hesitant
about IEEE 754 floating point values, because Double.NaN seems more convenient
than 'null' for missing values to me. Added arguments there:
http://jira.codehaus.org/browse/GEO-103#action_91724
Martin
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
