Hi, > The performance patch I submitted needs to keep track of which parts of > the map view need to be re-painted and which don't. Right now, the code > works like this: modify a few things -> call a global repaint on the map > view. The "client" code not only needs to know how to modify primitives, > but also how to update the view. If I now want to limit the repaint to > just the areas that have been affected by the change, this means that > each and every piece of "client" code has a third responsibility - > keeping track of the damaged area. > Contrast this with an MVC approach: "client" code updates the data. The > view listens for the change and this is it. Voila: one responsibility > (modifying primitives) instead of two or three. How, exactly, would this > be harder to use?
Ok, then let's do it in small steps in order to (a) break as little as possible and (b) give everybody a chance to understand what's happening. Let's make the spatial index our concrete goal and do whatever is required to get this off the ground. Do you propose having the spatial index as part of the OsmPrimitive object, or would you recommend having an extra "display" object instance to sit next to each OsmPrimitive that handles these things? We'd need protected access to the node position and member list for ways (and relations for good measure), right? Do we also have to protect the tag set or other features, initially? I suggest you provide a patch that has the required accessor methods WITHOUT making the member variables private as a first step. Then we can apply that patch and then make sure all plugins etc. use the accessors, and *then* we make the members private. After that you have a clean encapsulation on which you can build a spatial index. Sounds reasonable? Bye Frederik _______________________________________________ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
