Thinking about it further, switching to Iterator would be very annoying for the simple matter that it means we can't do a simple getEntries().get(0). So I've come up with an interim solution that works better than what we currently have but uses the incremental parse model a bit more efficiently. I've created a FOMList impl that implements List around a Iterator. As the list is used, the iterator is consumed. It's likely hard to visualize now, but I think when I check the code in and y'all can see it, you'll get the idea.
- James Garrett Rooney wrote: > On 7/13/06, James M Snell <[EMAIL PROTECTED]> wrote: >> There are a number of aspects of the model api that have been bugging me >> for some time. >> >> For instance, >> >> Feed.getEntries() returns a List, however, Feed.getEntries().add(...) >> doesn't actually do anything. It makes more sense for Feed.getEntries() >> to return an Iterator given that it's primary purpose is iterating >> through the entries. Doing so also allows us to optimize the underlying >> Axiom code (which provides efficient element iterators). > > Returning a list is also problematic in that while modifications to > the list have no effect, modifications to the entries themselves will > (if I'm reading the code correctly, I haven't tried this) change the > underlying elements. Returning an Iterator at least makes it clear > that there was no deep copy type semantics going on. > >> There are also methods such as setCategories(List) that accept a list >> that I'd like to remove mainly because I haven't yet come across a use >> case in which building up the list of items separately then setting them >> on the element makes any sense. > > Note that without setCategories() you can't clear out the list of > categories, at least as far as I can tell. Perhaps a > clearCategories() method would be useful? > > -garrett >
