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

jh jh at foobar.de
Tue Aug 19 09:19:58 BST 2008


Hi,

Frederik Ramm schrieb:
> Given that you never simply change the coordinates of a node without 
> having a proper change command, it should be quite uncomplicated to 
> have that command change the node's index value as well when required. 
> And even if you found you had to encapsulate the node's lat/lon, this 
> would not mean that you'd have to encapsulate everything else or every 
> other object while you're at it. *If* you're willing to think about 
> this without prejudice. If, however, all you think when seeing JOSM 
> code is "Yuck, I wouldn't touch that", then don't say "There is just 
> no way to do it...".
Well, of course "no way to do it" is a figure of speech. There's always 
a way. Yes, we can update the index manually, after changes - 
everywhere. What about plugins? It may not be an API change in the 
strict sense, but a Plugin failing to update the index breaks the 
application. You can do all kinds of stuff. We could use Java just like 
a procedural language and create beautifully functioning applications 
that way. Or we could use AspectJ and load-time weaving to restore 
encapsulation despite the use direct field accesses. The questions 
remain: does it scale? Is it maintainable? Does it make sense?
Refactoring is a well-established concept in the software development 
world right now. It is well understood under which circumstances it is 
applied and when it isn't. Usually this boils down to: leave the code in 
a better state than you found it.
> "Wholesale" means: "I'm going to refactor all this because it is not 
> written in the style I want to work with". I don't support that. First 
> think about what you want to do, then think what needs to be changed 
> to achieve that, then make the changes you need. ONLY the changes you 
> need. Not 100 other changes that you think someone else might also 
> need at some point in the future ("and while I'm here I'll also fix 
> this and that...").
Well, frankly what I read between (and not so much between) the lines is 
that the maintainers don't want the issues to be fixed. I smell a 
constant uphill battle about whether or not something needed to be 
refactored or not, especially given. And I'll be absolutely straight 
here: this isn't something I want to get involved with.
>> I don't see that NG or NG-2 would fly at this point.
>
> I don't see why not. I'm astonished why everybody is so eager about 
> fussing around with a piece of software they think has the crappiest 
> design ever when they could instead contribute to a clean, new 
> approach. I'd rather have those people who are comfortable with the 
> way JOSM is written work with JOSM, and those who are not work with 
> JOSM-NG, and I have no doubt that if you'd invest in JOSM-NG the same 
> time you're willing to spent refactoring JOSM, then JOSM-NG would 
> indeed fly. The sheer rendering performance would make many people 
> want to switch.
Investing in JOSM or -NG makes a very crucial difference: one is 
scratching itches, the other is getting deeply involved with another 
open source project. As long as -NG cannot be used for day to day 
mapping, there's no itching and thus no scratching.
I am already involved with several open source projects in varying 
depths, from one-time patch-submitter to owner. My interests in JOSM are 
just that: scratching itches. You may argue that my refactoring proposal 
is way more than just scratching, and I am the first to assert that I 
tend to be sucked into stiff like that easily. But what I definitely 
won't do is to invest into a ground-breaking effort - no matter how 
clean, nice and smart -NG may be (sorry Petr, please don't take it 
personally).
Oh, and to answer the initial question: I just egocentrically assumed 
that the motivation for a lot of prospective contributors might be 
similar. Investing into something one already uses and with proven value 
is nice and dandy, but not into something new.

Joerg




More information about the josm-dev mailing list