Zitat von Martin Desruisseaux <[EMAIL PROTECTED]>:
> Just my 2 cents: it may help if we stay a little bit conservative in
> method access ("public", "protected", etc.). Begin with private, turn
> into protected or public as needed (it is much easier to turn a private
> method into a public one than the converse).
Funny, I didn't consider this a problem. On the contrary. I really hate it when
private functions make it possible to use them in a subclass. And subclassing
(and extending classes) is important for projects building on GeoTools.
(There was an article somewhere in the net about this... on some blog I think.)
So imho protected methods are usually (not always) the better choice.
> Future javadoc tools (targeted for J2SE 1.6) may provide different views
> for basic/advanced methods using "public" and "protected" access.
Nice approach. Yes, this would make the JavaDoc better for beginners. But it has
two drawbacks:
1. It does only work for people that read the external JavaDoc. For instance I
read the JavaDoc in the source code directly, so I'd still see all methods,
woudn't I?
2. Just "hiding" advanced methods (in whatever way) is just one aspect of a
user-friendly high level API. I believe that it will take to *distinct* APIs to
reach this aim, even if this means more maintnance work.
.. and by the way. What's the use of J2SE 1.6 while GeoTools is on Java1.4?
Would we still be able to use this new JavaDoc function?
Matthias Basler
[EMAIL PROTECTED]
----------------------------------------------------------------
This mail was sent through http://webmail.uni-jena.de
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
