Re: API/javadoc - classes/methods that should not be public

[Crescent Enterprise <cres -at- cres -dot- com>]

On Fri, 20 Apr 2001, David Price wrote:

> Doing a little poll here,

I'd like to see a clean solution to this too, if someone's got one. In
the mean time whether to show the dirty linen or not would depend, for me,
on the state of the API and the expectations of the audience. Usually the
readers are technical and understand ragged edges. The
main concern would be to get warnings in the unsupported methods - put the
warnings at the method level and also a general warning up front.
I think I remember Microsoft getting castigated a few years
back for withholding parts of an API. You might ruffle some feathers doing
so, however well intentioned. A programmer isn't going to use an unsupported
part of an API, if he/she can avoid it, or at the very least they'll call
you to find out its status.

Steve Whitney
Takoma Park, MD


^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

*** Deva(tm) Tools for Dreamweaver and Deva(tm) Search ***
Build Contents, Indexes, and Search for Web Sites and Help Systems 
Available 4/30/01 at http://www.devahelp.com or info -at- devahelp -dot- com

Sponsored by DigiPub Solutions Corp, producers of PDF 2001 Conference East, 
June 4-6, Baltimore, MD. Now covering Acrobat 5. Early registration deadline 
April 27. http://www.pdfconference.com. 

---
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot-  Visit 
http://www.raycomm.com/techwhirl/ for more resources and info.