[josm-dev] Difference between JOSM and JOSM-NG

[Frederik Ramm]

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