You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "Maarten Billemont (JIRA)" <ji...@apache.org> on 2008/10/09 14:54:44 UTC
[jira] Created: (WICKET-1866) MarkupContainer already follows the
contract of Iterable; it should implement it.
MarkupContainer already follows the contract of Iterable; it should implement it.
---------------------------------------------------------------------------------
Key: WICKET-1866
URL: https://issues.apache.org/jira/browse/WICKET-1866
Project: Wicket
Issue Type: Bug
Components: wicket
Affects Versions: 1.4-M3
Reporter: Maarten Billemont
To support the enhanced for syntax and several other features of the language; MarkupContainers should implement the Iterable interface whose contract it already follows.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1866) MarkupContainer already follows the
contract of Iterable; it should implement it.
Posted by "David Shepherdson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-1866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12799588#action_12799588 ]
David Shepherdson commented on WICKET-1866:
-------------------------------------------
>From the perspective of a caller of the API, I don't see that there would be any problem with changing the signature of the existing iterator() method to make it compatible with the Iterable interface; looking at the code for MarkupContainer, it already actually returns an Iterator<Component>, and if the signature was changed to
public Iterator<Component> iterator()
...then anybody's existing code that does something like
Iterator<? extends Component> children = container.iterator();
...would still work, because Component satisfies the ? extends Component specifier.
Is your concern about subclasses of MarkupContainer that override iterator() using the same signature? In other words, something like
public class MyContainer extends MarkupContainer {
@Override
public Iterator<? extends Component> iterator() {
return ...;
}
}
...would no longer be valid if the signature of MarkupContainer's iterator() was changed, since ? extends Component is incompatible with Component at the superclass level.
It would be nice to be able to use the 'modern'-style for loops with MarkupContainers, and it's not like it would be a lot of effort to add the 'implements Iterable<Component>' and change the signature of iterator(), but I can see where you're coming from if you're worried about breaking anybody's legacy subclasses of MarkupContainer.
Is this something that might be reconsidered for the next major release (since small API changes on major releases are not unheard of)?
> MarkupContainer already follows the contract of Iterable; it should implement it.
> ---------------------------------------------------------------------------------
>
> Key: WICKET-1866
> URL: https://issues.apache.org/jira/browse/WICKET-1866
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.4-M3
> Reporter: Maarten Billemont
> Assignee: Igor Vaynberg
>
> To support the enhanced for syntax and several other features of the language; MarkupContainers should implement the Iterable interface whose contract it already follows.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1866) MarkupContainer already follows the
contract of Iterable; it should implement it.
Posted by "Igor Vaynberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-1866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12651114#action_12651114 ]
Igor Vaynberg commented on WICKET-1866:
---------------------------------------
there is a problem with generics here
currently markupcontainer has public Iterator<? extends Component> iterator() but if we make it implement iterable we have to change it to Iterator<Component> ... not sure which one is right.
> MarkupContainer already follows the contract of Iterable; it should implement it.
> ---------------------------------------------------------------------------------
>
> Key: WICKET-1866
> URL: https://issues.apache.org/jira/browse/WICKET-1866
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.4-M3
> Reporter: Maarten Billemont
>
> To support the enhanced for syntax and several other features of the language; MarkupContainers should implement the Iterable interface whose contract it already follows.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1866) MarkupContainer already follows the
contract of Iterable; it should implement it.
Posted by "David Shepherdson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-1866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12799978#action_12799978 ]
David Shepherdson commented on WICKET-1866:
-------------------------------------------
Thanks for your response, Igor.
The specific use case I had yesterday was in some test code -- wanting to confirm that some component-generating code had added the correct components to a container, so I wanted to grab a set of child ids to compare with my expected set. Doing that with a visitor obviously wouldn't be a big hassle (though a little more verbose than using the iterator), but it was more that when I saw that the interface in MarkupContainer looked so much like an Iterable, I wondered, 'Why not?'
Out of interest, what was the (presumably internal) use case for having the two iterator methods there in the first place?
> MarkupContainer already follows the contract of Iterable; it should implement it.
> ---------------------------------------------------------------------------------
>
> Key: WICKET-1866
> URL: https://issues.apache.org/jira/browse/WICKET-1866
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.4-M3
> Reporter: Maarten Billemont
> Assignee: Igor Vaynberg
>
> To support the enhanced for syntax and several other features of the language; MarkupContainers should implement the Iterable interface whose contract it already follows.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1866) MarkupContainer already follows the
contract of Iterable; it should implement it.
Posted by "Igor Vaynberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-1866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12799979#action_12799979 ]
Igor Vaynberg commented on WICKET-1866:
---------------------------------------
i dont really have a strong opposition to this now that we have 1.5 under way which will have tons of api breaks anyways, so whats one more?
but
the usecases for iterator() and renderiterator() are primarily internal. in your test it probably makes a lot more sense to structure your code like this:
for (String knownid:knowids) { asserttrue(container.get(knownid)!=null)); }
rather then iterating over components directly...
> MarkupContainer already follows the contract of Iterable; it should implement it.
> ---------------------------------------------------------------------------------
>
> Key: WICKET-1866
> URL: https://issues.apache.org/jira/browse/WICKET-1866
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.4-M3
> Reporter: Maarten Billemont
> Assignee: Igor Vaynberg
>
> To support the enhanced for syntax and several other features of the language; MarkupContainers should implement the Iterable interface whose contract it already follows.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1866) MarkupContainer already follows the
contract of Iterable; it should implement it.
Posted by "David Shepherdson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-1866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12800033#action_12800033 ]
David Shepherdson commented on WICKET-1866:
-------------------------------------------
I would have done it that way, but I need to make sure that the container has exactly the component ids I'm looking for -- no more, no less. So I think I'd still need to be able to tell if there are any other components there beyond the ones I'm expecting.
Although, having said that, I suppose I could combine a loop through the expected ids with a check of container.size(), which would tell me that there aren't any others. Though in that case, if there were more ids than expected, I'd then want to find out what the extra ones were so I could produce a helpful test failure message, so I'd probably end up with a loop or visitor again anyway. :-)
> MarkupContainer already follows the contract of Iterable; it should implement it.
> ---------------------------------------------------------------------------------
>
> Key: WICKET-1866
> URL: https://issues.apache.org/jira/browse/WICKET-1866
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.4-M3
> Reporter: Maarten Billemont
> Assignee: Igor Vaynberg
>
> To support the enhanced for syntax and several other features of the language; MarkupContainers should implement the Iterable interface whose contract it already follows.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WICKET-1866) MarkupContainer already follows the
contract of Iterable; it should implement it.
Posted by "Igor Vaynberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-1866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Igor Vaynberg resolved WICKET-1866.
-----------------------------------
Resolution: Won't Fix
Assignee: Igor Vaynberg
> MarkupContainer already follows the contract of Iterable; it should implement it.
> ---------------------------------------------------------------------------------
>
> Key: WICKET-1866
> URL: https://issues.apache.org/jira/browse/WICKET-1866
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.4-M3
> Reporter: Maarten Billemont
> Assignee: Igor Vaynberg
>
> To support the enhanced for syntax and several other features of the language; MarkupContainers should implement the Iterable interface whose contract it already follows.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1866) MarkupContainer already follows the
contract of Iterable; it should implement it.
Posted by "Igor Vaynberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-1866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12799620#action_12799620 ]
Igor Vaynberg commented on WICKET-1866:
---------------------------------------
what is the usecase for this? the preferred way to iterate components is to use the visitors, iterating children directly is a pretty rare usecase. we may consider it for 1.5, but i would like to know the usecase first...
> MarkupContainer already follows the contract of Iterable; it should implement it.
> ---------------------------------------------------------------------------------
>
> Key: WICKET-1866
> URL: https://issues.apache.org/jira/browse/WICKET-1866
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.4-M3
> Reporter: Maarten Billemont
> Assignee: Igor Vaynberg
>
> To support the enhanced for syntax and several other features of the language; MarkupContainers should implement the Iterable interface whose contract it already follows.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.