[josm-dev] Spaghetti code

[Igor Shubovych]

Ok. Sorry for that flame.

Regards,
Igor Shubovych

2009/2/5 Frederik Ramm <frederik at remote.org>

> Hi,
>
> Igor Shubovych wrote:
>
>> But what about small refactoring steps. Step by step the code better.
>> As I see it is histrorical problem, you didn't want to broke the plugins.
>>
>
> There is absolutely nothing to say against stepwise improvement! If someone
> says "I need to change this because otherwise I cannot implement this cool
> new feature" then he's unlikely to be told "please don't".
>
> However, in the past we have had people who wanted to make lots of internal
> changes to JOSM for the perceived benefit of "easier maintenance" or "better
> future development possibilities" or so. I.e. there was no tangible benefit,
> no "if I make this change then JOSM users will be more productive tomorrow",
> but instead something like "if I make this change then perhaps other
> programmers will come along and implement cool features and then perhaps
> JOSM users will be more productive".
>
>  With current design JOSM cannot evolve fast.
>>
>
> See, you're one of them already ;-) you say that the design needs to be
> changed to make it possible that JOSM evolves fast. You don't have a
> concrete promise for us, you just *assume* that JOSM will evolve better if
> the design is changed. There is no proof for that; your guess is as good as
> mine.
>
> Evolution is a dangerous thing. It works by making random changes and then
> killing off everything where the change did not bring an advantage.  I'd
> hate to see JOSM being changed and then killed ;-) so let's take it slow.
>
> What I normally say is: If someone implements something new, and in the
> process of doing so, wants to change something in JOSM's design, then by all
> means do so. For example, there is a public class member somewhere and you
> implement a new feature that depends on being notified when this member
> changed. Of course you can and will make that member private and implement
> the proper accessors. (And you will also re-compile all plugins afterwards
> and see if they still compile ;-) - but you should not needlessly make *all*
> members of that class private ("since I am editing this file, why not go all
> the way..."). Unless you have a good reason of course.
>
>
> Bye
> Frederik
>
> --
> Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00'09" E008°23'33"
>