[Noel]
Please document the List-specific methods that embody this critical
contract.
As mentioned in my previous post. The contract implied by List goes
further than the additional methods exposed. (The contract of DNS server
currently assumes that the Collection returned actually contains
InternetAddresses. You can't deny that that contract exists. You can't
document the methods that embody it either.)
[Noel]
- Returning a Collection implies only that from the
perspective of the client the exposed behavior is
that of a Collection. Nothing more or less.
Not true. An interface does specifiy the contract with the client. It also
specifies the contract with its implementation classes. The contract with
our implementation is that there must be an order to the address returned.
[Noel]
The key issue here appears to be the entirely false premise that Collection
implies a lack of order, and the equally false premise that List implies
anything about order other than index.
Wrong. The (correct) premise is that Collection does *not* imply the
/presence/ of order. Sure, it doesn't imply the absence either. It takes
order *out* of the contract. We all agree that "The semantic ordering
required by RFC 2821 is mandatory".
Also covered in my previous post - Yes, List implies order by index. No,
order by index is not strictly what we need. The fact remains that there
is no class in the java collections api that contracts order by MX
preference. Unless you want to write a whole new collection class, then we
need to make do with what we have.
This whole thing comes down to the fact that you read the contract implied
by this piece of code differently to me. In light of the support that this
point of view appears to have on this list, I suggest that my reading of
this contract is the more commonly reached one. This implies to me that
the use of List is interpreted by other developers in a manner that
encourages correct implementation of the DNSServer contract. Others do not
appear to have been mislead into thinking that the index is the important
point.
Bear in mind that I have agreed with several of your points. However, on
balance, it is my opinion that List - while not the idealistically perfect
solution - is the best compromise available. Grey lines again. Both you
and Serge have correctly pointed out that it doesn't matter very much at
the end of the day. I do like a good technical discussion, however! :-)
BTW - I agree with the unmodifiable collection thing.
Cheers
ADK
--------------------------------------------
There is no magic.
"Noel J.
Bergman" To: "James Developers List"
<[EMAIL PROTECTED]>
<noel@devtech. cc:
com> Subject: RE: [PATCH] Upgrade to DnsJava
1.3.1, add DNS Server autodetect, Make use
of higher level api
23/01/2003
07:57
Please respond
to "James
Developers
List"
OK, let me back this up to First Principles. We ought to be able to agree
on the following points:
1. The semantic ordering required by RFC 2821 is mandatory.
2. The ordering is based upon any preference indicated by
the MX record.
3. There may be more than one entry with the same preference.
4. Ordering of records with the same preference is required
to be randomized.
[RFC 2821: "If there are multiple destinations with the
same preference and there is no clear reason to favor
one (e.g., by recognition of an easily-reached address),
then the sender-SMTP MUST randomize them to spread the
load across multiple mail exchangers for a specific
organization.]
5. There may be more than one IP address for a given host.
6. IP addresses for a given host must be tried in the order
presented.
[RFC 2821: "The destination host (perhaps taken from the
preferred MX record) may be multihomed, in which case
the domain name resolver will return a list of
alternative IP addresses. It is the responsibility of
the domain name resolver interface to have ordered this
list by decreasing preference if necessary, and SMTP
MUST try them in the order presented.
That is the contract mandated by RFC 2821, and it does required an order.
Hopefully we can also agree on another point:
7. One of the fundamental principles of object programming is
implementation hiding.
What does implementation hiding mean? It doesn't mean that the behavior of
a class is hidden. It means that the implementation of that behavior is
hidden. In this case, it is semantically important that the client be
given
contents in a certain order, but how that order is computed or how it is
maintained should be opaque to the client.
The key issue here appears to be the entirely false premise that Collection
implies a lack of order, and the equally false premise that List implies
anything about order other than index.
If either of those false premises were true, we wouldn't be having this
argument.
I am presuming from the arguments presented that everyone is in favor of
strong typing. Fine. But this is also not an issue of strong vs weak
typing. Earlier Serge raised the issue of Object vs Collection, saying
(paraphrasing) that methods would just return Object if type didn't matter.
The difference is that we would need to cast from Object to a Collection,
but we don't need to cast from a Collection to a more specific type in
order
to access the necessary behavior. If we never need to know anything about
an object other than that it IS an Object, then returning an Object would
be
perfectly valid, because that interface provides the desired behavior.
Anything more specific that the interface that provides the necessary
behavior begins to violate the principle of implementation hiding.
INTERNALLY, as a matter of implementation, we receive an array from
DNSJava,
and we sort that array with Array.sort. After that we create a Vector from
that array, and return the Collection. The Collection interface provides
the ability to get an Iterator, and iteration is the only behavior we allow
of a client. In fact, I am quite tempted to insert a call to
Collection.unmodifiableCollection() in our implementation.
But, you say, List provides order! It says so! This is a
misinterpretation
of what List means by order. What List means by order is the ability to
manipulate the list by index. If our client code needed to manipulate the
results, having the ability to manipulate the order of the collection using
the index would be a compelling argument. But our clients only iterate.
Iteration is opaque. The whole point of an Iterator is implementation
hiding. Switching to List violates the principle of implementation hiding
by mandating that our iteration be index based. Furthermore it does not
buy
us the benefit that people seem to believe that it would.
Look at the code as it exists today. Change the signature to return List,
and comment out the Array.sort call. You would have a List that is of no
value. You would have enforced nothing, nor implied that there is an
important semantic order was important.
Now, as for some specific comments:
> The salient fact is that a /contract/ accompanies the List interface.
> This contract is critical to our application and does _not_ accompany
> the Collection interface.
Please document the List-specific methods that embody this critical
contract.
> returning a list provides a degree of compile-time checking
> for adherence to our required contract, returning a
> Collection does not.
There is no such benefit, as indicated by my observation regarding the
removal of Array.sort in the code. From the perspective of the provider,
we
must still document the semantic contract, and they must still implement
it.
The client must still take the Iterator, and trust that it is in the
correct
order. Therefore I consider this to be demonstrably false: returning a
List
does not provide any useful degree of compile-time checking, and prevents
the use of any other Collection subclass that would provide the correct
behavior.
> Returning a Collection implies that any Collection could be substituted.
- Returning a Collection implies only that from the
perspective of the client the exposed behavior is
that of a Collection. Nothing more or less.
- Returning a List adds nothing more or less than
the presence an index ordered relationship between
elements. Exposing a List violates the principle of
implementation hiding unless the interface contract
requires index-based behavior.
Charles did the correct thing when he hid the implementation, and exposed
the narrow interface. If anything, the change that I might make would be
to
change the return type from Collection to Iterator. Iteration is the only
permissible operation allowed to our client code, and the only reason for
our client code to have a Collection is to avoid having to rebuild the data
set in order to renew the Iterator. We should probably use
Collection.unmodifiableCollection() to enforce the immutable nature of the
provided contents.
Again, if someone can demonstrate the List methods that embody this
presumed
contract, I'm happy to listen. The fact that we don't use methods other
than those found on Collection belies the necessity, in my view.
--- Noel
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-----------------------------------------------------------------------------------------------
Have you seen our website?.... http://www.vodafone.co.nz
CAUTION: This correspondence is confidential and intended for the named recipient(s)
only.
If you are not the named recipient and receive this correspondence in error, you must
not copy,
distribute or take any action in reliance on it and you should delete it from your
system and
notify the sender immediately. Thank you.
Unless otherwise stated, any views or opinions expressed are solely those of the
author and do
not represent those of Vodafone New Zealand Limited.
Vodafone New Zealand Limited
21 Pitt Street, Private Bag 92161, Auckland, 1020, New Zealand
Telephone + 64 9 357 5100
Facsimile + 64 9 377 0962
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
