[
https://issues.apache.org/jira/browse/WICKET-6165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15464111#comment-15464111
]
Pedro Santos commented on WICKET-6165:
--------------------------------------
Hi Thorsen, thank you for reporting the error and the patches.
As most of wicket-core is built on top of the iteration style: read, move, do
it again if current index is inside the stream; it's better to simple fix the
name.
> Inconsistent behavior of Markupstream.hasMore vs. MarkupStream.next.
> --------------------------------------------------------------------
>
> Key: WICKET-6165
> URL: https://issues.apache.org/jira/browse/WICKET-6165
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 7.3.0
> Reporter: Thorsten Schöning
> Assignee: Pedro Santos
> Priority: Minor
> Attachments: HtmlHandler.java.patch, MarkupStream.java.patch,
> MarkupStream.java.patch
>
>
> {CODE}
> hasMore: return currentIndex < markup.size();
> next: if (++currentIndex < markup.size()) {...}
> me: while (markupStream.hasMore()) {...}
> {CODE}
> I get a null element within the while loop which I wouldn't expect to get.
> markup.size() is 73, currentIndex 72, so "hasMore" returns true, while "next"
> returns null, because it already advanced the index during its check.
> "hasMore" saying "yes" while "next" saying "no" seems inconsistent to me,
> even though one can check the return value of "next" against "null".
> Shouldn't "next" use
> {CODE}
> if (currentIndex++ < markup.size()) {...}
> {CODE}
> to be in line with "hasMore"? Or more better directly call "hasMore" for the
> check itself to have only one single consistent implementation of the check?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
