>> 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?
Map<K, V> iterates over keys (since it extends Collection<K>).
Pivot's collections all follow the same pattern:
List<T> : Sequence<T>, Collection<T>
Map<K, V> : Dictionary<K, V>, Collection<K>
Set<E> : Group<E>, Collection<E>
It wouldn't make sense to make Sequence iterable, since Lists are iterable (via
Collection).
> Iterating over a list using indices is sooo 90ies. Why can't I simply write:
>
> for (Object row : tableView.getSelectedRows()) {
> ...
> }
That's true, but getSelectedRows() is primarily meant to be a convenience
method. The primary means of obtaining a table view's selection is
getSelectedRanges(). This method returns an instance of ListSelectionSequence,
which could (and probably should) implement Iterable.
You might suggest that getSelectedRows() return a List. We don't do this
because it might imply that the return value is a "live" collection to which
the caller can listen for updates, which is not the case.
> 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.
I agree - these methods should be better documented.
