[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