Project roadmap

Hello folks,

I know this is a project made after the 2 hours Daniel spent to make the QuadTree videos, but I think it could either benefit from either:

Being renamed to QuadTreeExample (because it's definitely just a bunch of examples, at least for now 😄 )
Split into smaller packages.

Just saying this because we have very common classes here (Point, Rectangle…) that could be used as simple geometry for any kind of project based on a canvas, and the QuadTree one that depends on the Geometry one.

Or then rename this project to Geometry and put everything in it in separate files 🤣 .

What do you think?

Thanks for this comment! I agree that QuadTreeExample is probably a better name. I was thinking that this could become a JavaScript QuadTree library (with testing and npm releases), but that might be overly ambitious. I would like it to be generic and not dependent on p5. I have an idea for how to do this by having each Point object store a reference to any generic object, i.e.

let particle = new Particle(100, 100);
let point = new Point(particle.x, particle.y, particle);
qtree.insert(point);

Then when you ask for an array of points via query() you can iterate over the Particle objects themselves.

Er, I'm thinking about the Particle part... Even though it can be a different subject, I think it should be the contrary: a particle would need a point, but a point should just be an abstraction of something with x, y (and z?) coordinates. A particle has more concrete behaviors than a single point, so I'd imagine something more like this:

let point = new Point(100, 100);
let particle = new Particle(point);

The qtree would need something containing a point, but could contain wayyyy more things that are not particles. I'm not sure how we could do something like this (in PHP, where I come from (😛) we would do this with an interface).

For the npm & release part, IMO the lib should first focus on good practices of development, at least to keep examples consistent for the repo & the fact that you created them based on a video that might be seen many times 😄. Making it a "standard library" (tests, etc) would only be a second step, and possible only if a QuadTree library does not yet exist in the JS world 😉

The first idea of the Point having a reference to an object, or even function, array or any other kind of data, seems more appealing to me. An object somehow connected to the QuadTree does not necessarily need to know about a point, but the point should know (or be able to know) about an object it is "representing" in the quadtree (the general considerations in OOP, you know).

To give an example: What if you were using p5.js and p5.Vector? Or matter.js and its vector classes? Or your own vector classes etcetera etcetera etcetera...

The point (😄) is that we don't want to force our user into using a certain point or vector representation and its API. Rather, we would only "force" him to do so if he is working with the quadtree library and its implementations of points and other geometric objects. If he really wants to, he can use those for his one purposes as well, but he doesn't have to.

My idea for the API: Point has a property object, which might be set by the constructor.

I actually implemented this today and it worked really well! I think I'm not going to consider this a library, but rather an "example." If someone wants to fork it and make a "proper" library I'd certainly love that.

FYI other examples:
https://github.com/timohausmann/quadtree-js
https://github.com/silflow/quadtree-javascript
https://github.com/d3/d3-quadtree

More soon!

I'm totally 👍 for adding an object (or subject maybe?) property to Point! I was mostly arguing about the particle part, because IMO this "subject" should be an abstraction that can mix types, not a fixed one.
Sounds totally legit to me, and it could be a recursive relationship: for example, a Particle is associated with a Point, and the Point "carries" the Particle as a "subject". This allows using the Point class in any library 😄

@shiffman

@shiffman regarding unit tests, I'm currently in the process of writing a bunch of unit tests. I'm hoping to push up a PR today or tomorrow. Need to add more based on the pull requests that have merged since I forked

@Pierstoval

Maybe it is better to call the Point class different.
Something like QuadTreeData or so.
Then you know that it is not a "normal" point like @Pierstoval mentioned.

Navigation Menu

Repository navigation

Project roadmap #4

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Project roadmap #4

Description

Activity

shiffman commented on Mar 27, 2018

Pierstoval commented on Mar 27, 2018

kleinesfilmroellchen commented on Mar 27, 2018

shiffman commented on Mar 27, 2018

Pierstoval commented on Mar 27, 2018

Dezzles commented on Mar 27, 2018

Maik1999 commented on Apr 10, 2018

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions