[OSM-dev] Josm-patches and osm-lib was:OSM Date Formats
Marcus at Wolschon.biz
Wed Oct 3 17:43:40 BST 2007
-----BEGIN PGP SIGNED MESSAGE-----
Frederik Ramm schrieb:
> you'll soon have your plugins call all sorts of "initialize" and
> "setup" routines just in case you need them in the future
What would there be to initialize other then that the plugin
needs to get itself into a state to work?
> 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).
You mean you don't want to document a program you are writing?
I thought the aparent lack of javadocs was just lack of time and
bad style and not even remotely on purpose.
> If you set the expectation that plugins will continue to work even if
> you make major updates,
Do you make that promise now?
I don't see where a major change would break less
plugins now then if you let us make it follow proper style.
> 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).
You are the only one talking about a stable and documented plugin-api.
Everyone else seems to talk about an offer to implement proper
coding-style on existing classes. This adding of getters, setters,
final arguments, javadoc, parameter checking in non-performance-critical
parts would cost you no work at all because the offer was to implement
that for you.
Proper style helps other developers understand, use and debug your code.
Thus it helps to get more eyes into the project and ease the writing
of patches and plugins.
If I found a bug the choice of filing a bug-report versus submitting a
patch for it is made on the easy of writing that patch for code I am
not working with on a daily basis.
You seem to make a lot of assumptions about providing a stable contract
to implement where you would actually be left with a documentation
stating what return-values may be null and what parameters are
acceptable and thus what third party code is NOT to rely on.
Currently one takes the code and relies on it to be working the
same way for the next few versions when writing a plugin because there
is nothing where you can see "this may be null", "these may be called
in any order", "this is not guaranteed to be already updated when that
As you don't seem to want it. Okay.
I'll not offer to do this work for
My vacation starts in a few hours and I'll probably
be away from internet untill next week.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the dev