Hi, >> true conviction that many things will actually be *harder* to do once >> they've done their work, not *easier* (especially for programmers who >> are not Java experts). > > Why do you think that this is the case?
Proper encapsulation often brings with it a kind of non-straightforwardness. The first example to come to my mind, but surely not the only one, is the usual concept of listeners and event sources. It's second nature to people using it on a daily basis, but quite difficult to follow for someone who doesn't. If you have a "window.repaint()" somewhere then everyone understands what this means, but if you fire an event which will be caught by whoever has registered as a listener then the casual viewer of the code has to find out who registers as a listener and when and what they'll do with the event. 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. Now you'll say that that must have been bad design then, but take something like Swing which is surely designed by people who should know, and does work quite well, but it's a nightmare if you think you could just invest an hour and "scratch an itch" below the shiny surface. I haven't seen code designed by any of those calling for wholesale refactoring because of the "yuck" factor. They could be reasonable programmers who know when to do something by the book and when it serves nothing but to demonstrate that they have read the book. They could also be people who can't deal with anything they have not written themselves. How would I know if they pile up demands about what has to be changed with JOSM before they even touch it? > Refactoring is supposed to make code easier to understand for everyone, > not easier to understand for code ninjas and harder to understand for > the general population. Do you think that it's impossible to make JOSM's > code easier to understand and work with for everyone? 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. >> Will I, as the JOSM maintainer, be able to count >> on these people to actually do the important work (i.e. adding features, >> fixing bugs and so on) AFTER they have turned JOSM inside out - or will >> they just continue to find reasons why they cannot contribute to JOSM as >> it is, or (even worse) move on to refactor something else, thinking >> they've improved JOSM when in fact they have made life more difficult >> for the existing developers, all with the promise that it will surely be >> easier to attract new ones? > > 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? >> JOSM is currently designed in such a simple fashion that I can honestly >> ask someone who is only a C++ or Ruby or whatever programmer to >> implement features. > > Genuine question: how often does this happen? JOSM doesn't have a lot of developers, but I have already mentioned Dirk who says of himself that the last time he programmed Java was many years ago, and I believe you have read David Earl's posting earlier in this thread. There are about three or four other people working on JOSM with varying intensity and that's it. > 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. 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. > How about one person like Dirk and twenty people all contributing > because the design has been cleaned up? That would be ideal but I doubt it. Or at least I see a very big danger of going over board in refactoring. At least Dirk seems to have had no problems in dealing with JOSM as it was when he joined (search for subject "JOSM code quality"). > Who has suggested that this is their plan, or given any indication that > this might be what they are up to? 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. I'm sorry but I cannot believe that these people actually care for OSM and want to help improving life for the mappers. Get involved, take a share of the responsibility, and then work with the others to get things done, that's the way it would work. But coming into the room wielding your Best OO Pracices book and telling everyone how crappy everything is (and by the way you're willing to relieve them of their misery and share some enlightenment) is just not the way to achieve success. With behaviour like this you'll hit a brick wall everywhere. (Recent example: Torvalds talking about people who show up and the first thing they do is submit a giant patch to the Linux kernel: http://news.zdnet.co.uk/software/0,1000000121,39462454,00.htm?r=9) I'm getting tired of this conversation and I believe everyone else is, too. I'm doing what I do because I think it is best for JOSM and its users. I'm not claiming a monopoly here. Go contribute to JOSM-NG (or, by the way, Merkaartor which reportedly is also well-written). Go check out JOSM and build a replacement if you can't be bothered to help JOSM-NG. Or help improving JOSM, slowly. I found Joerg's idea of heading in the MVC direction for the map display, and having a good spatial index to support fast drawing, quite good and I also think this is something where we could attempt a small scale refactoring, limited to what is actually needed to reach that goal. Joerg is at least someone who has taken the effort to work with the existing code and knows whereof he speaks. (I have already written that you don't even need accessors to implement a spatial index but if Joerg's willing to do the work then it's probably fair to let him decide how he does it... as is custom elsewhere in OSM.) Maybe the whole discussion is also blown out of proportion by the fact that we haven't really defined what refactoring means. If I were to toy with optimizing the drawing routines and I wound that I can triple drawing speed if I introduce better encapsulation for some of the properties, I would probably just do it without saying that I "refactored" the code. When I hear "refactoring" I always think of someone using his Eclipse or whatever to encapsulate every single public variable even if he doesn't have a clue what it is used for, instead of doing focused work aimed at reaching a goal. Bye Frederik -- Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00'09" E008°23'33" _______________________________________________ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
