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.
So how about this then:
public interface Container extends Component { public List getComponents(); public void addComponent(Component component); public void removeComponent(Component component); }
I think it's a good idea to return a LIst; that way, you can go through it forwards or backwards.
One danger with returning a mutable list is that the Collections class has a method:
pubic class Collections {
...
public void reverse(List list);
...
}
What that does is it reverses the list itself, rather than returning a new copy that is reversed. So if someone did:
Collections.reverse(container.getComponents())
then they'd actually end up reversing the order of the container's components, which is Not A Good Thing
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.
Plus, if it's mutable, then you can do:
container.getComponents().add(new Applet())
which again isn't desirable.
What I propose is that you return a read-only wrapper of the class (which only needs instantiating once), and then if at a later stage we find we need write-through functionality we can look at (a) why, and (b) if there's a better way of doing it.
public interface Container extends Component {
private List mutable = new LinkedList();
private List immutable = Collections.unmodifiabeList(mutable);
public List getComponents {
return immutable;
}
public void addComponent(Component c) {
mutable.add(c);
}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?
I'd also question; is 'addComponent(Component c)' more readable/descriptive than 'add(Component c)'? We know it's a container, which is designed to manage components, so hopefully it's obvious that it's components you're adding ...
Alex.
