Hi, > the main benefit of encapsulation is to make code more flexible > for refactoring, internal changes, performance optimization > through implementation hiding
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.) > in case of modular software like josm with plugins is > encapsulation a must for development and has not only something to do > with clean style of code Developing a clean plugin interface is very hard work because you have to define lots of hooks for the plugin to access; you have to know in advance what a plugin might want to do and you have to actually write code for every single one of these hooks. A plugin might want to display something; might want to listen on a TCP port; might want to send events to various components; might want to show up in the load dialog; might want to be called before data is uploaded; and so on. All these interfaces will need to be maintained and tested every time you make changes, and half of the time the plugin developer would still not find the hook or access method that he needs, extending the JOSM core with extra stuff. 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. We operate in a very dynamic environment and it is very important for us that plugin developers can do whatever they need. It is very hard to predict what they will need; we have a much broader scale of plugins than, say, a graphics filter in a drawing program. So I maintain that large-scale encapsulation in JOSM will make things much more difficult for plugin developers *and* JOSM maintainers, or at least take a lot of flexibility away from plugins that they currently enjoy. I challenge you to implement a good plugin interface that doesn not suffer from these problems. If you can do that, we'll use it, including whatever necessary encapsulation comes with it. If you can't, or if half of the existing plugins will require ugly workarounds to keep working, then please re-think your condescending attitude towards JOSM's design. Bye Frederik _______________________________________________ josm-dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/josm-dev
