Aaron,
> I agree with the unmodifiable collection thing.
NOTE TO SERGEI: would you please put that in when you prepare the new
submission?
> I do like a good technical discussion, however! :-)
If you want to continue this one, let's do everyone else a favor and take it
off-list. I don't mind the discussion, either, but I don't want it to be
disruptive to others.
Discussion after sign-off.
--- Noel
> The contract with our implementation is that there must be an
> order to the address returned.
I agree that such a semantic contract exists.
> The (correct) premise is that Collection does *not* imply the
> /presence/ of order. Sure, it doesn't imply the absence either.
> 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.
We agree on all of those points.
This is where we differ:
> The contract implied by List goes further than the additional
> methods exposed.
> This whole thing comes down to the fact that you read the contract implied
> by this piece of code differently to me.
We will have to agree to disagree on this point. I don't believe that there
is any additional contract implied by the List interface, I don't think that
an implied contract can be verified by the compiler, and more importantly,
the notion of implied contracts would also apply to the method in question,
thus relieving us of any mandate to change it. :-) On the negative side,
using a List would preclude our ability to replace the internal
implementation with some other collection that implemented our semantic
contract.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
