Noel J. Bergman wrote:
Well, you're using a straw man argument IMHO. The question is whether the interface should change, and you're talking about how the underlying implementation behaves.Change from Collection->List sounds good to me. Will go ahead and makethischange in a day or two unless someone objects or gets to it sooner.The method returns a Collection of servers. At the time when we use the Collection, all that we can know, without changing the content of the Collection, is the order and value of the elements. Each Collection class provides its own Iterator type. If the actual Collection is sorted, the order is not lost; the underlying object is still the same. Any decision about sorting can be done within the method when it decides which subclass of Collection to return. In this case, we use a Vector. Vector is an AbstractList, and the provided Iterator iterates through the contents in order. If there is any sorting to do, we can do it before returning the Vector. When we use the Collection in RemoteDelivery, for example, we get an Iterator from the Collection, and use it: Iterator i = targetServers.iterator(); I haven't seen anyone provide a justification to change the current interface. Whatever policy we want to manage the MX records can be handled by the current interface, from what I've seen.
The reason to change the interface is that MX Records have an ordering, so the interface that returns a IP addresses based on MX records should return something that indicates that this is ordered. Right now our interface does not indicate it is ordered. Sure, we are *implementing* the ordering, but the interface isn't accurate and hence needs to be changed.
Serge Knystautas
Loki Technologies
http://www.lokitech.com/
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
