[OSM-dev] Josm-patches and osm-lib was:OSM Date Formats

Frederik Ramm frederik at remote.org
Wed Oct 3 15:41:28 BST 2007


> Using a public member forces the higher level routines to have to
> 'know' about the details of the implementation of the lower level.
> If you suddenly decide to swap out structure A with indexed
> structure B, you can happily do this and just update the
> getter/setters, knowing that all of the code that has already been
> written is accessing the information through the getter/setters and
> other public interface routines and will continue to work without
> change. On the other hand, having plugins access public members
> directly means that when you make changes, you have to go back and
> modify and recompile all of the plugins.

Everything you say is correct BUT: If you nicely encapsulate the JOSM
inner workings and make JOSM "provide services" to plugins, then you
have already committed yourself to (a) really keep stuff compatible
(there's a multitude things that may require more complex changes than
you can easily do in a getter and setter - if you start on that path
you'll soon have your plugins call all sorts of "initialize" and
"setup" routines just in case you need them in the future, and to (b)
document your API properly (and most of all think about which methods
make up you API and which should rather be "undocumented" meaning that
folks can use them but not rely on them being there forever).

If you set the expectation that plugins will continue to work even if
you make major updates, then you will have to live up to that
expectation, meaning that making changes is MORE work, not less, on
the part of the JOSM core, and you run the danger of petrifying old
structures just for the sake of compatibility with some old stuff.

I think one of the reasons JOSM is like it is is that there wasn't
a lot of manpower available for development, and it would have been
too much "bureaucracy" work for Imi (deciding what to offer to plugins
and what to shield from them, taking responsibility/guaranteeing that
stuff will continue to work, documenting the API etc).

If we have enough manpower now to do this, maybe we can and should do
it to make life easier for plugin developers. But, again, this would
require a thorugh understanding and concept of where exactly the 
Core <-> Plugin "fault line" a.k.a. API should run, plus the
commitment of a handful of people to actually work to that
specification in the future.

Simply and mechanically replacing every public variable with a getter
and setter gets you nowhere, indeed it signals that using these
getters and setters would always be safe (and forces you to make them
that way for the forseeable future).

All I'm saying is let's take this slowly, let's think about what we
want to achieve and then do that instead of blindly refactoring
working code just for the sake of compliance with what others do.


Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00.09' E008°23.33'

More information about the dev mailing list