FWIW, I agree with Serge on this one. Returning a List implies that the
contents are ordered. (Which order is not specified, of course.)
Returning a Collection does not imply that.
Returning a SortedSet would imply that the contents are both ordered
*and* that there are no duplicates. The choice between these two
interfaces obviously comes down to whether or not we require uniqueness.
If your contention is that we should not preclude ourselves from
switching from List to SortedSet in future, then I believe that simply
indicates a lack of understanding of the requirements.
If the requirement is not known at this point, then deferring the
decision is a good choice, so the Collection should stay. If the
requirement is known, then we should choose the interface that most
closely matches the requirement.
If the requirement is that we be able to support either possibility,
then what we really need is an OrderedCollection interface, from which
both SortedSet and List derive. I do not believe that this is really
the case.
The fact that List provides no additional methods that we wish to use is
neither here nor there. 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. Sure,
the current implementation does honour the required contract. It does
that only because the implementation class happens to be of a type that
does have that contract.
Returning a Collection implies that any Collection could be substituted.
This is not true. Returning a List implies that any List would do the
job. This *is* true!
The more of our contract that is designed into place, as opposed to just
documented into place, the better.
At the end of the day, returning a list provides a degree of
compile-time checking for adherence to our required contract, returning
a Collection does not. Sure, it would be better still to have checking
for the ordering criteria too, but the cost/benefit ratio of providing
this does not stack up.
Cheers
ADK
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
- Re: [PATCH] Upgrade to DnsJava 1.3.1, add DNS Server auto... Harmeet Bedi
- Re: [PATCH] Upgrade to DnsJava 1.3.1, add DNS Server auto... Serge Knystautas
- Re: [PATCH] Upgrade to DnsJava 1.3.1, add DNS Server auto... Harmeet Bedi
- RE: [PATCH] Upgrade to DnsJava 1.3.1, add DNS Server auto... Noel J. Bergman
- Re: [PATCH] Upgrade to DnsJava 1.3.1, add DNS Server auto... Serge Knystautas
- RE: [PATCH] Upgrade to DnsJava 1.3.1, add DNS Server auto... Noel J. Bergman
- Re: [PATCH] Upgrade to DnsJava 1.3.1, add DNS Server auto... Serge Knystautas
- RE: [PATCH] Upgrade to DnsJava 1.3.1, add DNS Server auto... Noel J. Bergman
- Re: [PATCH] Upgrade to DnsJava 1.3.1, add DNS Server auto... Serge Knystautas
- RE: [PATCH] Upgrade to DnsJava 1.3.1, add DNS Server auto... Noel J. Bergman
- RE: [PATCH] Upgrade to DnsJava 1.3.1, add DNS Server auto... Aaron Knauf
- RE: [PATCH] Upgrade to DnsJava 1.3.1, add DNS Server auto... Noel J. Bergman
- Re: [PATCH] Upgrade to DnsJava 1.3.1, add DNS Server auto... Serge Knystautas
- Re: [PATCH] Upgrade to DnsJava 1.3.1, add DNS Server auto... Serge Knystautas
- RE: [PATCH] Upgrade to DnsJava 1.3.1, add DNS Server auto... Noel J. Bergman
- Re: [PATCH] Upgrade to DnsJava 1.3.1, add DNS Server auto... Harmeet Bedi
- Re: [PATCH] Upgrade to DnsJava 1.3.1, add DNS Server auto... Harmeet Bedi
- RE: [PATCH] Upgrade to DnsJava 1.3.1, add DNS Server auto... Noel J. Bergman
- Re: [PATCH] Upgrade to DnsJava 1.3.2 + revision 2 of my o... Harmeet Bedi
- RE: [PATCH] Upgrade to DnsJava 1.3.2 + revision 2 of my o... Noel J. Bergman
- Re: [PATCH] Upgrade to DnsJava 1.3.2 + revision 2 of my o... Harmeet Bedi
