Frederik Ramm wrote: > I think if someone came along with a real good performance optimization > for JOSM that, as an aside, requires more encapsulation than JOSM > currently has, that would be a very good reason to add said encapsulation. > > Trouble is, until now we have had a lot of textbook lectures on how > everything would be much better if only we had proper encapsulation, but > never anything tangible. (Much like on the talk list, where every few > weeks someone comes around and says "what, you n00bs not using > PostGIS?", to which the much-iterated reply is: show results.)
The trouble with this logic is that it doesn't reveal or account for the hidden costs. For example, how can I evaluate how much more likely it would have been that I would currently be a JOSM contributor if I hadn't taken one look at the code and said "Ick"? I can't, but it's a non-zero effect. And how many more people are there like me? By its very nature, it's impossible to tell how many more contributors there would be, and how much better the code would be, if it was written more in line with standard Java best practice. But Petr and I are at least two data points. There's a great book called "Economics in One Lesson" by Henry Hazlitt. Even though it was written 50 years ago, the one lesson is still relevant. It is: "The art of economics consists in looking not merely at the immediate but at the longer effects of any act or policy; it consists in tracing the consequences of that policy not merely for one group but for all groups." http://en.wikipedia.org/wiki/Economics_in_One_Lesson The effects on some groups are particularly hard to measure if they consist of someone not doing something they would otherwise do, such as contributing to JOSM. It's like governments putting up taxes. The visible benefit they claim is that they can spend more money on improving the lives of their citizens. The hidden cost is that each citizen has less money, and so they don't buy things they otherwise would and there's less economic activity. What things? Impossible to tell. But it's a cost nevertheless. > Currently, JOSM doesn't care for plugins; everything is more or less > wide open, and a plugin can do almost anything that JOSM itself could. > Sometimes when you work on JOSM, you break a plugin; but on the whole, > JOSM development is not hindered by myriad plugin hooks that have to be > maintained, and plugin development is not hindered by having only access > to a small plugin API. This makes it easy for both plugin developers and > JOSM developers - at the occasional expense of stability. This is an entirely reasonable plugin model IMO; but it makes it all the more important for JOSM objects to hide their internal state from plugins using accessor methods and protected member variables. That way, you can override something if you need to be doing a derived class, but it means that plugins can't accidentally mess with stuff they shouldn't be. Gerv _______________________________________________ josm-dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/josm-dev
