Ok. Sorry for that flame. Regards, Igor Shubovych
2009/2/5 Frederik Ramm <[email protected]> > 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 [email protected] ## N49°00'09" E008°23'33" > _______________________________________________ josm-dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/josm-dev
