[
https://issues.apache.org/jira/browse/LUCENE-7314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15318797#comment-15318797
]
Nicholas Knize commented on LUCENE-7314:
----------------------------------------
Like the class naming discussion I'm fine w/ whatever agreement can be reached.
:) Things always change. FWIW this was my experience early on:
bq. I suspect new users would start with Lucene's core, expecting to find
usable defaults there for common use cases
When I first started looking at spatial I immediately looked in the spatial
module for everything spatial and assumed (by the name) the core module
contained foundation dependencies required by other modules. I've also spoke
with quite a few spatial shops that have been interested in contributing but
are very confused by the location of lucene's spatial classes (clearly
something that needs to be fixed). Like many devs they assume package and
module names are self explanatory and don't RTFM (or is it RTFJD?) until
they're totally confused. Unfortunately, the spatial javadocs didn't help them.
bq. ...we would have javadocs there that point you to the
spatial/spatial-extras to do more expert things
This approach has always been fine w/ me - again, javadocs. It certainly wasn't
the agreed approach earlier when I proposed promoting the postings based
GeoPointField (which has the same public API) to core way back when. Back then
even basic spatial was considered a "special use-case" that belonged in a
spatial module. It sounds like this view has partially changed? :) (at least
for "good default" spatial capability)
bq. It's clearly important we make Lucene easier to use for the common use
cases and by hiding away LatLonPoint in the spatial module, here, we fail to do
that.
I totally agree but part of this comment scares me. Just for my own
understanding how do modules "hide away" good functionality (especially if
they're well named)? If this is true isn't it a disservice to organize
good/advanced/{insert adjective} functionality in separate modules?
+0 to move specifically to core.
+1 to postpone moving until an agreement can be reached.
> Graduate InetAddressPoint and LatLonPoint to core
> -------------------------------------------------
>
> Key: LUCENE-7314
> URL: https://issues.apache.org/jira/browse/LUCENE-7314
> Project: Lucene - Core
> Issue Type: Improvement
> Reporter: Adrien Grand
> Assignee: Adrien Grand
> Priority: Minor
>
> Maybe we should graduate these fields (and related queries) to core for
> Lucene 6.1?
--
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
