Marking deprecated would also need to be configurable or at least at a "FYI" level rather than giving any real indication of error. If it's "your" code using deprecated code, then it's likely close to an error to use a deprecated method, but sometimes you're forced to do so. (As an example, try overriding a Sun deprecated method like JComponent.setVisible(boolean). The moment something calls show() or hide() [which you'd think they would've simply redefined to point to setVisible(true) and setVisible(false)] you're screwed.)
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Jonas Kvarnstr�m Sent: Wednesday, February 20, 2002 12:33 PM To: [EMAIL PROTECTED] Subject: Re: [Eap-list] Marking JavaDoc errors DOMMASCH Alex wrote: >I agree that it should be configurable. (I'd probably choose something >like purple - noticeable, but not overly alarming.) I also agree that >documentation errors are serious, but not fatal. I.e., a system with >documentation errors can still meet all functional requirements. To >me, documentation errors are at a similar "warning level" as using >deprecated methods - OK for the moment, but really bad for the future. > Hmm. How about adding automatic syntax highlighting for deprecated methods? Of course, this would involve parsing the javadoc in the source to see whether each method is deprecated... Or is this information available in the .class files? Maybe this would be too much effort for too little gain. _______________________________________________ Eap-list mailing list [EMAIL PROTECTED] http://www.intellij.com/mailman/listinfo/eap-list
