But then we're left with the problem of how to deal with situations where you need to go through the components in reverse (someone - Greg? - brought up an example of this earlier) - this isn't possible with a ListIterator unless, as Alex suggetss, you iterate through to the end and then iterate back again, which doesn't strike me as the most elegant of solutions. :)
Adrian -----Original Message----- From: Jason Dillon [mailto:[EMAIL PROTECTED] Sent: 14 August 2003 13:26 To: [EMAIL PROTECTED] Subject: Re: [General] Container interface and AbstractContainer If the list should not be mutable, then it makes more sense to return an Iterator (or ListIterator as mentioned), else someone could violate the contract and insert random fluff into the list instead of using the add/remove methods. --jason On Thursday, August 14, 2003, at 07:13 PM, Greg Wilkins wrote: > > > James Strachan wrote: >> How's this? >>>> public interface Container extends Component { >>>> public ListIterator getComponents(); >>>> public ListIterator getComponentNames(); >>>> public void addComponent(Component component); >>>> public void removeComponent(Component component); >>>> } > > > But then Adrian Jackson wrote: >> From: Alex Blewitt [mailto:[EMAIL PROTECTED] >>> Can you use ListIterator to go from the end? >> You can work from the end if you *start* at the end (by passing an >> appropriate argument to the listIterator() method of your list) but >> once you've got the iterator you're limited to working backwards and >> forwards. If we want complete flexibility of how to navigate the >> collection of components, then returning a List rather than a >> ListIterator might be the only option. > > I guess there is a reason it took java 2 iterations to get collections > sort of right :-) > > So how about this then: > > public interface Container extends Component { > public List getComponents(); > public void addComponent(Component component); > public void removeComponent(Component component); > } > > But then we have the question - should the List be immutable or not? I > think it should be a write through list, as this is a core class and > should be as flexible as possibe. So it is worth the effort to > support the full Collection API. > > However, while this is working towards a good abstract Collection, I > would still like to hear from Dain or Jeremy what they intended the > plugin methods to be for and where they should go? > > > > > > > >
