was added relatively late in the cycle and overloading seemed to be the best choice for the DSL.
On the FullTextQuery I'd rather avoid creating more overloaded methods so I'd like to hear some alternative proposals, but I generally agree something seems to be missing.
Note that both DistanceSortField and Point are declared in an .impl package and are not meant to be used directly, the fact that they are used in unit tests was a mistake, I should have noticed. We should rather create a user friendly way to create these; for example sorting should be provided by the DSL (linking to HSEARCH-1217).
For the Point.getDistanceTo(Coordinates other), I don't think you should use the Point class at all but if you can explain the nice use case backing up why we should expose the distance calculation we could think of making a public helper class; I would expect people to use projections instead?
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
Hi Xavier, thanks you made some good points.
Method
On the FullTextQuery I'd rather avoid creating more overloaded methods so I'd like to hear some alternative proposals, but I generally agree something seems to be missing.
Note that both DistanceSortField and Point are declared in an .impl package and are not meant to be used directly, the fact that they are used in unit tests was a mistake, I should have noticed. We should rather create a user friendly way to create these; for example sorting should be provided by the DSL (linking to HSEARCH-1217).
For the Point.getDistanceTo(Coordinates other), I don't think you should use the Point class at all but if you can explain the nice use case backing up why we should expose the distance calculation we could think of making a public helper class; I would expect people to use projections instead?