lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Muir (JIRA)" <>
Subject [jira] [Commented] (LUCENE-7056) Spatial3d/Geo3d should have zero runtime dependencies
Date Tue, 01 Mar 2016 17:00:19 GMT


Robert Muir commented on LUCENE-7056:

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? 

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. 

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?

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:
>             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

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message