> > I understand, and I am all for meaningful contracts. My point is that a
> > Java Collection is not unordered. It can be either ordered or
unordered,
> > based upon the implementation class.
> Yes, this is my point... we should not leave it up to the implementation
> as to whether it is ordered or not.
> Since the MX record query produce an ordered set of IP addresses,
> I'm saying the interface should return an ordered collection.
I understand that you want a contract that tells the client that the
collection is ordered. The catch is that there is nothing in the Java
Collection classes that exposes any notion of semantic ordering other than
Comparator.
When accessing a Java Collection, there are only two possible orders:
Iterator and/or index. What the List hierarchy introduces is an index.
Being given a List only means is that you have an index with which to
manipulate or examine the List. From the presence of an index are derived
additional behaviors such as backwards iteration, insertion at an index,
etc., all of which are based upon the index, not the data. None of those
behaviors are necessary for our code. All that we care about is that there
is an appropriate semantic order provided by the Iterator. No other
ordering is exposed as an interface contract to a client anywhere in Java.
A client accepts the ordering provided by the Interator, and that behavior
is deliberately opaque to the client.
As a client of the DNS, I just want to be told that when I iterate over the
entries, that they will be in an MX priority order. Getting a List as
opposed to a Collection does not provide me with that semantic. List does
not introduce a semantically useful Iterator order, unless you consider the
index within the list to be the desired semantic. The fact that it is in
some useful order is because the code that creates the Collection, prepares
it with an order, and returns an object that will preserve that order. It
could be a List or any other type of Collection that provides the order
during iteration.
List is only one of the ordered collection types. So long as the MX record
query returns a priority ordered collection, I don't care what
implementation type is used. And there is no interface contract that
describes the desire. Nor is there anything I can do with the data once
retrieved, because all that I have are the target host strings. Any data by
which the client could ensure the result has been discarded.
Now, if you say that the index is useful by itself, or if you say that you
want the client to be able to re-sort the contents, then we have a different
discussion. But if all that we're trying to do is provide a strongly typed
interface contract to the client that says this is an ordered collection,
then I hope I've shown why List doesn't accomplish that task.
By adopting List, all that we'd be exposing to the client is that the
Collection has an index, which the client would never use. We would not be
saying anything about the semantic order, we've discared the data that would
allow the client to enforce or verify it, and we'd be precluding our ability
to use another type of ordered collection in the future.
The underlying DNS code returns an array of records. Currently we convert
that to a Vector of target host names as String objects, discarding all
else. We might, at some point, change or enhance the interface to return a
collection of MX records sorted by priority. We could easily implement a
non-indexed sorted Collection that allows duplicates. We already have the
Comparator in our code. But if we were to replace one collection
implementation with another in the future, we'd have to change the method
interface unless we kept it as Collection. So I don't see why keeping it as
Collection is considered a problem (note: it always has been a Collection
from the first instance of the code), and I do see an issue with adopting
List.
If I am missing something, I'm sure that you'll explain.
--- Noel
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
