Greg Brown <[email protected]> wrote:
This approach allows us to combine collection behaviors without
collisions on the Iterable type (for example,
org.apache.pivot.xml.Element implements List<Node> and
Dictionary<String, String>, which wouldn't compile if Dictionary
also implemented Iterable).
I didn't suggest that Dictionary<K,V> should implement Iterable.
I would not be feasible anyway: should it iterate on the keys or the values?
So, you don't have a collision here.
We use Sequence rather than List in our inner classes primarily
because we want the associated mutator events to be fired from the
outer class, rather than the sequence itself, as we would need to do
if the sequences implemented List (they would need to fire
ListListener events).
I didn't suggest that sequences implement List. I suggested that they
extend _Iterable_, so that they have the iterator() method so that
they can be used in for-each. Iterable is unaware of ListListeners, so
sequences stay unaware of it, too. (ListListeners are in the realm of
List, which is on top of Sequence.) I don't understand what you mean
by saying that sequences would need to fire ListListener events if
Sequence extends Iterable.
To give you an impression why it is useful to have Sequence extend Iterable:
TableView tableView = ...;
Sequence<?> selectedRows = tableView.getSelectedRows();
for (int i = 0, len = selectedRows.getLength(); i < len; i++) {
Object row = selectedRows.get(i);
...
}
Iterating over a list using indices is sooo 90ies. Why can't I simply write:
for (Object row : tableView.getSelectedRows()) {
...
}
Note that a developer who is unaware of the current implementation of
getSelectedRows() could even write the following:
for (int i = 0; i < tableView.getSelectedRows().getLength(); i++) {
Object row = tableView.getSelectedRows.get(i);
...
}
which performs horribly because the selected rows are copied to a new
ArrayList in a for loop in each iteration.
Dirk.
