[
https://issues.apache.org/jira/browse/LUCENE-7056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15173990#comment-15173990
]
David Smiley commented on LUCENE-7056:
--------------------------------------
bq. +1 from someone who is just started looking at this stuff. I think we need
to keep this stuff as simple as possible. Exposing a bunch of unnecessary API
makes things much more difficult. We've applied a similar approach to the other
point classes already.
Can you please explain how leaving it exposed (public) makes things "much more
difficult"? Or maybe you don't mean more difficult but just less "simple" by
virtue of people seeing it and being confused by cognitive overload of stuff
they won't need? If it's the latter and not difficulty in something else then
I think keeping purely the geometries separated and even better, out of Lucene,
helps. Keeping it package private would help too at the determent of others
who want to use this, and it would foster the continuation of this very large
Java package growing without organization. One of the biggest annoyances I
have with it is that each time I look in there I have to figure out which of
these classes are the Lucene ones. It's taken me an embarrassingly long time
on occasion to the point that I've resorted to my IDE's dependency analyzer to
tell me which are the Lucene ones. _Even if we don't agree to the entire aims
of this issue, I'd like to to consider separating these 2 classes out by
package. What do you think about that specifically?_
bq. If someone wants the geo3d math implemenation, alone, they can poach/fork
from us?
Because that's a large barrier to sharing / re-use. it's easy for you to
suggest this, living in the code base that has it, but please consider an
outsider. :-( Hearing this suggestion makes me sad; and the idea of making it
all package private even sadder.
bq. Lucene shouldn't try to be in the business of "exporting spatial math
libraries for others to use". We are a search engine, and our priorities here
are to make spatial indexing and searching work well.
Then why is Geo3d/Spatial3d even here at all? I'd rather it not be but I'm not
pushing for that today; just a compromise. Keep it here while it suits us.
You've made the point that it's easier/faster to iterate on Geo3d here and I
recognize that, so leave it here. Some day we will look back and see it has
stabilized, and I hold out some fleeting hope you might be convinced in the
merits of a dependency instead of maintaining it here. Not a dependency from
lucene-core or lucene-spatial, but lucene-spatial-extras.
bq. It's the same reason why we don't e.g. invest in making FSTs easier for
outsiders to use: these are internal data structures that we use to provide
awesome indexing/searching.
I don't think these are mutually exclusive. Of course there can be technical
decisions that trade off ease of use for performance and we'd rather choose
performance in many cases, but that doesn't mean it's a bad idea to expose a
library that others might use. If we were to do so, we wouldn't have to be
bound by annoyances like backwards compatibility if we chose not to. Part of
the thrill I get in contributing to open-source is knowing my code is used so
widely, and hearing kind remarks of its usefulness. Don't you?
bq. Actually 5.x also has the classes for Lucene users to index and search with
geo3d, under the org.apache.lucene.bkdtree3d package in the spatial3d module.
Oh yeah; I overlooked that for some reason; weird.
> Spatial3d/Geo3d should have zero runtime dependencies
> -----------------------------------------------------
>
> Key: LUCENE-7056
> URL: https://issues.apache.org/jira/browse/LUCENE-7056
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/spatial3d
> Reporter: David Smiley
> Assignee: David Smiley
> Fix For: 6.0
>
>
> This is a proposal for the "spatial3d" module to be purely about the
> shape/geometry implementations it has. In Lucene 5 that's actually all it
> has. In Lucene 6 at the moment its ~76 files have 2 classes that I think
> should go elsewhere: Geo3DPoint and PointInGeo3DShapeQuery. Specifically
> lucene-spatial-extras (which doesn't quite exist yet so lucene-spatial) would
> be a suitable place due to the dependency. _Eventually_ I see this module
> migrating elsewhere be it on its own or a part of something else more
> spatial-ish. Even if that never comes to pass, non-Lucene users who want to
> use this module for it's geometry annoyingly have to exclude the Lucene
> dependencies that are there because this module also contains these two
> classes.
> In a comment I'll suggest some specifics.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
