[
https://issues.apache.org/jira/browse/LUCENE-6578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14602943#comment-14602943
]
Michael McCandless commented on LUCENE-6578:
--------------------------------------------
bq. One thing abstractions can do, is reduce code duplication. The interface
"DistanceStyle" does exactly that – there are many ways to compute a distance
spatially. This change reduced the patch file by ~40%. Does anyone argue this
specific change was anything less than an improvement?
Code duplication is not the only metric that matters, and 40% reduction LOC is
a fluffed up metric ... how much smaller is it if we just remove the duplicate
javadocs?
In this particular case, I'm not sure I like the new abstraction, but I really
do not understand enough to make an informed decision. Can someone succinctly
explain what DistanceStyle abstraction represents? This is a burden every
newcomer to the geo3d APIs must grapple with / overcome.
It seems like [~daddywri] and [~dsmiley] are happy with this change so I won't
block it but I don't really like it. I think there should be a higher bar for
inventing new abstractions in the absence of actual usage of a new API.
> Geo3d: arcDistanceToShape() method may be useful
> ------------------------------------------------
>
> Key: LUCENE-6578
> URL: https://issues.apache.org/jira/browse/LUCENE-6578
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/spatial
> Reporter: Karl Wright
> Attachments: LUCENE-6578.patch, LUCENE-6578.patch
>
>
> I've got an application that seems like it may need the ability to compute a
> new kind of arc distance, from a GeoPoint to the nearest edge/point of a
> GeoShape. Adding this method to the interface, and corresponding
> implementations, would increase the utility of the package for ranking
> purposes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
