You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "ASF subversion and git services (JIRA)" <ji...@apache.org> on 2016/09/05 05:02:20 UTC
[jira] [Commented] (WICKET-6165) Inconsistent behavior of
Markupstream.hasMore vs. MarkupStream.next.
[ https://issues.apache.org/jira/browse/WICKET-6165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15464099#comment-15464099 ]
ASF subversion and git services commented on WICKET-6165:
---------------------------------------------------------
Commit e3e09fd002452c8d2ea4be18f2733cffda78fc10 in wicket's branch refs/heads/master from Pedro Henrique Oliveira dos Santos
[ https://git-wip-us.apache.org/repos/asf?p=wicket.git;h=e3e09fd ]
WICKET-6165 renaming MarkupStream#hasMore to MarkupStream#isCurrentIndexInsideTheStream
> 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)