Frederik Ramm schrieb:
> All I ever hear is "once we have a proper design, we will..." (be able
> to improve performance, attract more developers, whatever), and I simply
> don't believe these claims. As I said before, where are all the Java
> experts flocking to JOSM-NG because of its clean design? As I said
> before, it would only take a few Java Expert man-days to get JOSM-NG to
> "fly".
>
As I already explained: -NG suffers from competition with something that
already exists and can be used.
> JOSM is currently designed in such a simple fashion that I can honestly
> ask someone who is only a C++ or Ruby or whatever programmer to
> implement features. I fear that once I've let the Java crowd have their
> way, this will be much harder.
I don't quite see how a good design and encapsulation makes it harder do
work with the code. In fact, it is the job of a nice and clean design to
make it easy. Just to give you an example of what I mean:
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?
The understanding for a dire need of refactoring was the result of my
experience implementing this performance patch. Doing so, was needlessly
difficult and the road to uncovering its full potential using spatial
indexing even stonier.
> I have said, more than once, that I'm absolutely open to design changes
> as long as they're connected to a specific goal ("I have to change this
> in order to be able to implement that"). What I won't accept is design
> changes as an end in itself. I know Imi's not around to defend his
> design choices but please be reminded that Imi is a Java developer who
> *knows* exactly how things are "usually" done and who has chosen to
> implement JOSM as we see it *for a reason*, and not out of ignorance.
> I'm not saying this is set in stone but I'm also unwilling to offer JOSM
> as some sort of playground where people may play out their design fetishes.
Well, the goal of my proposal was just that: opening the way to be able
to refactor without breaking all bridges. Nowhere did I mention that
refactoring is and end in itself. I still don't understand why this is
met with suspicions of fetishism, but I don't seem to be the only one to
have been bitten by this stance. This may well be the reason why you
have twenty people telling you about the need for refactoring with none
of them staying on board: discouragement. As I said: so many interesting
projects, so little time.
Joerg
_______________________________________________
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev
