[
https://issues.apache.org/jira/browse/LUCENE-3610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13159718#comment-13159718
]
Hoss Man commented on LUCENE-3610:
----------------------------------
That's one example ... some of the other methods i was mentioned deal with
(either as an argument or as a result) two element arrays of doubles ... which
one comes first in the array? ... you can't fix that by renaming the variable.
in either case: is there really any downside against having a simple object
that wraps the latlon pair so you *always* know which one is which? is the
RAM/GC overhead of an object like i described really significant compared to a
double[2] ?
> Revamp spatial APIs that use primitives (or arrays of primitives) in their
> args/results so that they use strongly typed objects
> -------------------------------------------------------------------------------------------------------------------------------
>
> Key: LUCENE-3610
> URL: https://issues.apache.org/jira/browse/LUCENE-3610
> Project: Lucene - Java
> Issue Type: Improvement
> Components: modules/spatial
> Reporter: Hoss Man
> Fix For: 4.0
>
>
> My "spatial awareness" is pretty meek, but LUCENE-3599 seems like a prime
> example of the types of mistakes that are probably really easy to make with
> all of the Spatial related APIs that deal with arrays (or sequences) of
> doubles where specific indexes of those arrays (or sequences) have
> significant meaning: mainly latitude vs longitude.
> We should probably reconsider any method that takes in double[] or multiple
> doubles to express latlon pairs and rewrite them to use the existing LatLng
> class -- or if people think that class is too heavyweight, then add a new
> lightweight class to handle the strong typing of a basic latlon point instead
> of just passing around a double[2] or two doubles called "x" and "y" ...
> {code}
> public static final class SimpleLatLonPointInRadians {
> public double latitude;
> public double longitude;
> }
> {code}
> ...then all those various methods that expect lat+lon pairs in radians (like
> DistanceUtils.haversine, DistanceUtils.normLat, DistanceUtils.normLng,
> DistanceUtils.pointOnBearing, DistanceUtils.latLonCorner, etc...) can start
> having APIs that don't make your eyes bleed when you start trying to
> understand what order the args go in.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
