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?
