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

[Gervase Markham]

Frederik Ramm wrote:
> I have had many unhappy encounters with over-engineered Java code where
> I had to dig through byzantine arrays of classes, most of which did
> nothing but delegate something to some other class - you were at A and
> wanted to pass a message to B, requiring you to change signatures on
> methods of C, D, and E just to pass through that extra bit of info,
> things like that.

Well, if you see something like that in a submitted patch, you can
object. But that's no reason to tar everything called "refactoring" with
the same brush, and to object to it all on principle.

> I haven't seen code designed by any of those calling for wholesale
> refactoring because of the "yuck" factor. 

Apart from the JOSM-NG codebase, you mean?

> I am sure it is possible to make JOSM's code easier to understand and
> work with for many, but I'm also sure that converting everything to use
> standard standard OO practices and design patterns will actually make it
> harder for people who want to contribute, and successfully have
> contributed in the past, unless they have prior Java exposure.

Java is not the only OO language.

>> Why do you think refactoring will make your life more difficult?
> 
> The existing developers are used to working with the existing code. Is
> it not obvious to you that a major style change will require everyone to
> get used to the new way of doing things?

I don't think major changes will happen overnight. If you like, you
could impose a requirement that patches had to come with documentation.

>> What makes you think that best practice in other OO languages (with
>> which these people will hopefully be familiar)
> 
> I think if we'd make it a requirement that people should "hopefully be
> familiar with best practice in other OO languages" then we'd lose half
> of JOSM contributors.

You said you wanted to allow C++ or Ruby programmers to contribute. So I
said that the best practices in those languages are likely to be similar
to best practices in Java.

If you want to allow programmers to contribute who are not familiar with
best practices in any language, then what you really seem to be asking
for is bad programmers :-) They aren't called "best practices"
arbitrarily, you know.

> Is it possible that you are seeing JOSM primarily as a programming
> project, one in which programmers invest their time because they like
> programming? Because in my eyes it isn't.

JOSM is a programming project, in that it's a project whose main
activity is programming. OSM is a mapping project, which JOSM helps to
enable. Programmers may invest their time in JOSM because they like
programming, but are more likely to do so because they like mapping. But
that's no reason to say that it doesn't matter if the code is of poor
design.

> We have had a number of people who showed up on the mailing list, their
> first post being something along the lines that everything needs to be
> refactored and they're willing to help. Then you tell them to take it
> slow, and then they're gone. 

That's not normally what you say, though. You normally get defensive and
say "it's all fine as it is".

If your response was instead "well, let's see your first patch" then
they might not be gone so fast. :-)

> I'm sorry but I cannot believe that these
> people actually care for OSM and want to help improving life for the
> mappers. 

You think there are gangs of troublemaking Java hackers roving the
internet, looking for software projects to mess up the design of?

Why else do you think they'd be here?

Doubting someone's good intentions is not a great way to start a
relationship. Do you think that perhaps this hostility, whether
explicitly expressed or not, might be a factor in scaring them off?

> Maybe the whole discussion is also blown out of proportion by the fact
> that we haven't really defined what refactoring means. 

You may well be right :-)

Gerv