You raise some good points, but I think you're over-thinking the solution :-)
People should only be using infinite data-structures as part of some kind of computation. i.e. as part of some section of algorithm-heavy code. They should not make it anywhere near the user interface code. At most we should protect our user-interface code by asserting that getLength() >=0. But I suspect that anything that makes this mistake will find out very very quickly (via an OutOfMemoryError), or by a program that pegs at 100% CPU, so I'm not even sure we need to do that. -- Noel Grandin On Sun, Jul 3, 2011 at 12:51, Chris Bartlett <[email protected]> wrote: > Example List implementations > - circular linked list > - nodes in a cyclic graph > - random number generator > - repeating decimal places (such as the decimal representation of 1/3) > > > > http://pivot.apache.org/2.0/docs/api/org/apache/pivot/collections/List.html#getLength() > The javadoc states - 'Returns: The number of items in the list, or -1 > if the list's length is not known. In this case, the iterator must be > used to retrieve the contents of the list.' > > In the case of the examples listed above, I would expect the List to > return a length of -1, which then means I should access its elements > via an Iterator. > > However there is no mention about any contract regarding the iterator > that the List implementation should return, and no way of asking the > List whether or not it represents a finite list of values. > > This could cause problems when such a list is used as the model for a > Pivot Component, as well as in general usage. > > One trivial example is the 'sizeToContent style in TerraSpinnerSkin. > When set to true, it will use an Iterator to calculate the maximum > rendered width of all elements in the Spinner's data model. This > would trigger an infinite loop for a List with an infinite number of > values. > Obviously, TerraSpinnerSkin could decide to only process the first x > many elements, or simply ignore the style if the length of the List > cannot be determined, but similar logic would be needed anywhere that > a Pivot List might be accessed via an Iterator. > > > I'm not really sure the preferred way to address this, but here are a few > ideas > > - Simply stress the *possibility* of an infinite sized list in the > javadocs for org.apache.pivot.collections.List, and suggest limiting > the number of iterations performed on an Iterator returned by a List > whose length is reported as -1. > > - Add a method method directly to List that would at least allow the > code using a List to see if it is of a finite length, but that would > be a breaking API change. > > - Override the iterator() method for List to have return type of a > Pivot subclass of Iterator which could be queried about its size. > Again an API breaking change. > public interface LengthIterator extends Iterator<T> { > public enum Length { > FINITE, INFINITE, UNKNOWN > } > public Length getLengthInfo(); > } > > - Creation of a FiniteIterator class which would would wrap any > existing Iterator and provide a means to limit the number of elements > returned by an iterator. This could be used to protect against > infinite loops by any code that iterates over all elements in a List. > (and/or a FiniteIterable class wrap an entire List) > > - Specify that repeated calls to hasNext()/next() on any Iterator > returned by a List should fail after X attempts (Integer.MAX_VALUE > ?). Calling next() after X attempts should throw a > MaximumIteratorSizeExceeded exception. This would prevent 'controlled' > access to Lists where the next (single) element is simple read as it > is required. > > Chris >
