To add to my argument (and I'm not trying to get you to change this patch by the way - its just javadoc, and I'm more interested in the argument than the results this morning ;) )
You could make a similar argument that links from one method referencing another in the same class are unneeded - you are already at the page. But they nicely scroll you to what you want to see. Same with the class link itself - if you are at the bottom of a long class and click the class link, it takes you to the top and definition of the class - the same way that when I am in next(), I can click a link to get to the increment() definition. - Mark Mark Miller wrote: > That depends - the links may end up in summaries on different pages > (first sentence as an exaple) - it also provides a consistent > formatting for class names so that they pop silmialry everywhere. I > don't agree with "it makes no sense." I'd make every classname > everywhere a link if I could. > > - Mark > > http://www.lucidimagination.com (mobile) > > On Aug 30, 2009, at 6:17 AM, "Uwe Schindler (JIRA)" <j...@apache.org> > wrote: > >> >> [ >> https://issues.apache.org/jira/browse/LUCENE-1875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel >> ] >> >> >> Uwe Schindler updated LUCENE-1875: >> ---------------------------------- >> >> Attachment: LUCENE-1875.patch >> >> Patxh with changed end() javadocs. This patch also removes the {...@link >> TokenStream}s inside TokenStream.java (it does not make sense to link >> to the same doc page itsself). >> >>> Javadoc of TokenStream.end() somehow confusing >>> ---------------------------------------------- >>> >>> Key: LUCENE-1875 >>> URL: https://issues.apache.org/jira/browse/LUCENE-1875 >>> Project: Lucene - Java >>> Issue Type: Bug >>> Components: Analysis >>> Affects Versions: 2.9 >>> Reporter: Uwe Schindler >>> Assignee: Uwe Schindler >>> Fix For: 2.9 >>> >>> Attachments: LUCENE-1875.patch >>> >>> >>> The Javadocs of TokenStream.end() are somehow confusing, because >>> they also refer to the old TokenStream API ("after next() returned >>> null"). But one who implements his TokenStream with the old API >>> cannot make use of the end() feature, as he would not use attributes >>> and so cannot update the end offsets (he could, but then he should >>> rewrite the whole TokenStream). To be conform to the old API, there >>> must be an end(Token) method, which we will not add. >>> I would drop the old API from this docs. >> >> -- >> This message is automatically generated by JIRA. >> - >> You can reply to this email to add a comment to the issue online. >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: java-dev-h...@lucene.apache.org >> -- - Mark http://www.lucidimagination.com --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
