[
https://issues.apache.org/jira/browse/LUCENE-7056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15174018#comment-15174018
]
Robert Muir commented on LUCENE-7056:
-------------------------------------
{quote}
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?
{quote}
That is part of it, but its more complex than that. To me its about making the
api intuitive for both users and ourselves (e.g. tests). For example the guts
of PointRangeQuery etc were all public, taking byte[][] arrays as inputs and
requiring you to use correct Point classes that match and so on. Same goes for
polygon etc queries in sandbox. Very error prone to use the wrong encoding when
we can just make it type-safe etc instead and only expose some methods like
IntPoint.newRangeQuery. And having a smaller public footprint means we can try
to make it really nice and really document the contracts of the methods. I
think this spatial stuff has enough trickiness that it really helps to make
everything we expose well-defined, safe, fast, etc.
I think it extends to this geo3d as well. I hate that the point class we
provide forces users to pass around PlanetModel to every ctor and method, it
makes it harder and more error-prone: instead we just make one thats wired at
WGS84, and consider a separate point class that is "expert" or "custom" that
works with other models.
{quote}
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?
{quote}
I agree that some separation can help. I think we should move the lucene
classes into a separate package at the moment to make this easier. This should
not really be controversial, lets take this small step. I had the same problem
as you here finding stuff.
Making a separate module in my opinion is not really helpful at the problem, it
just adds more indirection/confusion and more potential mistakes. I agree with
Mike that we shouldn't make these kind of compromises for non-search since we
are a search engine library.
> 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
