[josm-dev] Refactoring of the JOSM architecture vs. Plugins

Frederik Ramm frederik at remote.org
Tue Aug 19 11:27:00 BST 2008


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








More information about the josm-dev mailing list