[josm-dev] Difference between JOSM and JOSM-NG

[Dirk Stöcker]

On Mon, 11 Aug 2008, Petr Nejedly wrote:

> When we're at it, I'm not sure the way josm is written makes it any easier
> to work with the code. Using accessors is the standard way every java programmer
> understands and the code clutter is not much of an argument.

I do not like these either, but on the other side I also would not fix 
these without a good reason. Making elements private and fixing the 
sources to work with that is no big issue, but starting with current code 
I would do so only in cases, where encapsulation really brings benefit. 
Not for the general purpose of clean style.

> Moreover, josm uses unusual L10N way (I must admit that for a reason this time,
> though not a strong one)

>From my point of view Java uses an unusal system. The gettext is one of 
the best systems for that purpose I know of.

> Some of my ideas can be backported to JOSM directly ("Storage" class, which is
> a kind of HashMap with much smaller footprint), some with much more effort,
> "thanks" to the way josm is written (keeping a bbox of ways, having all the
> primitives stored in a QTree - the QTree approach needs the position writes to be
> intercepted, public fields is a big no-no for this).

>From my point of view reworks to achieve major improvements are fine. I 
personally would support that, when the improvement achieved are worth the 
problems which will occur based on major code changes (and for sure there 
will be problems).

So if we have a situation where there is a statement like:
"For that or that reason these variables should use Set/Get functions",
then step by step migrating the code to use Set/Get and
then making the variables private and
then implementing new stuff would be fine.

As said: I would support that, when I'm conviced the benefits are worth 
the troubles (and we have no reworking-all-dont-work-at-all phase). And I 
think Frederik has an equal opinion.

Ciao
-- 
http://www.dstoecker.eu/ (PGP key available)