Hi, Gervase Markham wrote: > standard Java-isms > industry best practice > Structural design patterns
I, for one, would like to also attract developers for whom maybe Java and OO are not the environment in which they spend all of their programming lifes and for whom a comment like "using decorator pattern here" is not very helpful. OSM is a project with an enormous breadth of programming languages and concepts, and I think we profit a lot from people being able to work across the board. This doesn't mean we should write Java as if it were Perl, but it also means that it is a good idea to keep things simple. > If working on performance, because the > class used for internal storage is exposed to callers, you can't e.g. > replace a linked list with a hash for efficiency reasons, or decide to > lazily compute the value from other values. Again, empty promises. If I find that I want to replace a linked list with a hash for efficiency in JOSM, I just do it and check whether the plugins still compile. Nothing has ever hindered me to do that precisely beause I am NOT doing things based on well-rehearsed textbook talk. If I wanted to please the "industry best practice" crowd then it would be totally inacceptable to make a change that perhaps breaks some unpublished plugin down the line. If I wanted to do it right, I would have to put up a corset of guaranteed properties on which plugins could rely, and beforehand I would have to encapsulate as much as possible away from plugins so that guaranteeing these properties will not break my ability to work with the code. Not having such a set of guaranteed properties gives me the freedom to optimize as much as I want, with the drawback that sometimes I might have to edit a plugin as well (and any unpublished plugins might break). > This and other considerations mean that any book you read on Java best > practice (or any object-oriented language, for that matter) will > recommend that you make your variables private and use accessor methods. [...] > Multiply that up for each change of this sort you want > to make, and you can see why people don't start down that rocky road. > The "stop energy" barrier gets too great. Past JOSM development proves you wrong. And JOSM isn't going to be a framework used by thousands of developers any time soon. I maintain that while it's all nice and shiny to put up standard practice rules, they are mostly very theoretical constructs based on the idea that someone might want to do something which might then break something else and everything would go down in flames. I maintain that for the software that JOSM currently is, with the purpose that JOSM currently has, and the developer community available to work on it, JOSM is just right. I concede that, if OSM were a project where hundreds of developers work on various aspects of JOSM, or if JOSM was an academic project where it is more important to show that you have understood a concept than to put it to practical use, or if JOSM was a commercial enterprise where instead of having a bunch of part-time programmers that sometimes aren't even Java specialist, you will have full-time experts working on it - I concede that in all these cases relying more on "Java-isms" and standard practices would be more in line with the goal. > You're right, I can't magically produce more developers if you agreed to > let people refactor the code to match best practice better. But I can > give you some reasons why the average Java programmer will find diving > into the current JOSM codebase an unappealing prospect. If given a choice, I'd rather have the average mapper dive into current JOSM, than the average Java programmer! > One reason perhaps is that open source projects are successful in > attracting developers when they already work (albeit imperfectly) for a > task. JOSM-NG is not yet even a basic OSM editor, because (as I > understand it) it can't return changes to the server. Something that would probably cost you one day to implement. 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
