Maintenance state? about quadtree HOT 9 CLOSED

Hi Ivan,

Thanks for your interest in the crate and your consideration for the userbase! I'd be happy to review any PRs from you on any topic, and I'll try my best to review them quickly, even same-day when possible.

Perhaps you could tell me a bit more about the changes you're interested in making? I don't personally know of anyone using this crate, so it would be fun to hear about possible applications.

from quadtree.

from quadtree.

That's pretty interesting, thanks for the insight.

• For overlapping / non overlapping regions, I think you could construct Quadtree with some settings struct and then check for collision at insert time. I would welcome PRs in this direction.

• With regard to entry API ergonomics, I have some APIs with get() and the returned Entry struct which mirror somewhat the entry patterns I observed in std::collections::HashMap. What sorts of changes should we make here? I would also welcome PRs in this direction.

from quadtree.

Side question: why does Area use Builder pattern, and what does Quadtree's with_anchor constructor does? Is it that you can omit anchor from Area if working with a Quadtree that has anchor set?

from quadtree.

• Area uses the builder pattern because I personally find it reassuring to know that I haven't forgotten to set either the anchor or the dimensions of an area. We use derive_builder for this. Put another way - when you insert an area, you need to supply both its width/height and an x/y location in the cartesian plane. But I found myself forgetting to supply one or another in tests and at callsites.
• new_with_anchor generates a new Quadtree whose anchor isn't necessarily the origin, (0,0) on the cartesian plane. It doesn't let you omit the anchor from an Area.

It sounds like I might be missing some documentation on Area?

from quadtree.

from quadtree.

The thing that's missing from Entry as compared to std::collections is the empty variant, and the associated ability to insert in it.

from quadtree.

The thing that's missing from Entry as compared to std::collections is the empty variant, and the associated ability to insert in it.

This sounds like a good design improvement to me. Like I mentioned above, I would be happy to review any PRs which address ergonomics. NB: we would have to bump the major version since this would be a breaking change.

from quadtree.

@JohnDowson: I noticed you've begun work (in #17, #18) on some of the features we've discussed here: (a) making overlapping / nonoverlapping regions, (b) different ergonomics for Entry, and maybe (c) cleaning up how we treat anchors.

I am going to close this issue -- please take out further more granular issues for each of the changes you want to make. Thanks! :)

from quadtree.