[josm-dev] Spaghetti code

[Stefan Breunig]

If classes need fixing, why not just add a new one
"classThatNeedsFixing2" with a proper implementation. Change JOSM to
use "2" in various places, let it bake and see if it needs any
additional feature and mark the old class as depricated and advise
develops to use "2" instead. That way all new devs will likely use "2"
and some other references to the old code will be changed as well. And
after say 3 months you can change all remaining calls from the old to
the new class. Users will likely have updated JOSM in the meantime so
that plugins can be changed as well.

Greetings
xeen

On Thu, Feb 5, 2009 at 01:51, Igor Shubovych <igor.shubovych at gmail.com> wrote:
> 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"
>>
> _______________________________________________
> josm-dev mailing list
> josm-dev at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/josm-dev
>



-- 
Please encrypt your mail:
http://mathphys.fsk.uni-heidelberg.de/~stefan/publickey.asc
FP: 2620 E737 FD50 60AB 86B6 1B9D 3BFD AFFB 5B15 6893