Refactor distances between geometries | Part 1

[lassepe]

First PR addressing #98

This allows Distances.evaluate et al. to work without a custom dispatch for the Point type.

Let me know if the dependency on Lazy.@forward is okay or whether we want to just forward manually for the three functions.

[lassepe]

The CI error on macos seems not related. It is some error during instantiation of the plotting packages.

[juliohm]

@lassepe unfortunately we can't merge this PR as it attempts to solve multiple things at the same time. See our contributing guidelines and start a PR with just the distance refactoring. Here you add a new dependency on Lazy.jl, you forward operations from points to coordinates, and other things that I didn't spend too much time reviewing.

We appreciate if you can follow the plan we brainstormed over Zulip.

[lassepe]

This is only attempting to solve one point of my comment in #98:

1. The correct way to implement the Distances seems to be to add a dispatch to the functor for the metric, rather than Distances.evaluate. By this means, the generic fallbacks for evaluate and pairwise et al should work out of the box.

If you look at the way Distances is implemented, you can't really add a dispatch to the metric functors because it generates the code:

https://github.com/JuliaStats/Distances.jl/blob/fa867d59098dd848fd71bc48005a1bf858928a47/src/metrics.jl#L328

Thus, I decided to implement a minimal iterator interface to make the generic methods from Distances.jl work.
That said, I'm happy to remove the dependency on Lazy.jl as stated in the PR description. Alternatively, one could also not change this part at all since Distances.evaluate would be deprecated by one of my next PR's anyway.

[juliohm]

I think Distances.jl evolved a lot since the first time I used it. It is worth checking what is the current approach to implementing new methods and if we need to follow it or just provide a high-level evaluate(D, point, point).

Regarding the iterator interface for points, we can't add it. A point is not the same thing as its coordinates in a coordinate reference system. A tuple of coordinates can be seen as iterable, but a point is an abstract concept with multiple types of coordinates.

[lassepe]

Regarding the iterator interface for points, we can't add it. A point is not the same thing as its coordinates in a coordinate reference system. A tuple of coordinates can be seen as iterable, but a point is an abstract concept with multiple types of coordinates.

Okay, that makes a lot of sense. I'll go another route then. I'm sorry for the noise.