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
_______________________________________________
josm-dev mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/josm-dev
