Prev: logging into site using form validation http components
Next: Windows priorities with runtime.exec
From: Eric Sosman on 7 Jun 2010 08:16
On 6/6/2010 4:32 PM, Stefan Ram wrote:
> Eric Sosman<esosman(a)ieee-dot-org.invalid> writes:
>> On 6/6/2010 2:25 PM, Stefan Ram wrote:
>>> Patricia Shanahan<pats(a)acm.org> writes:
>>>> I disagree with this relative to Javadoc comments. It is very, very
>>>> important to be able to tell what a method call will do without reading
>>>> its implementation.
>>> [...]
>>> (In my question, I was referring to documentation of /interfaces/,
>>> thus of, /abstract/ methods, which anyways do not need to have any
>>> implementation at all.)
>> Yes, but the contract of the method should state whether it
>> can return null and under what conditions, unless it's "obvious."
>> For example, consider the remove() and poll() methods of the Queue
>> interface: the contract for poll() says that it returns null if its
>> queue is empty, while that for remove() says NoSuchElementException
>> is thrown. These are not descriptions of particular implementations
>> that just happen to behave this way, but statements about how *all*
>> implementations are supposed to behave. The Queue interface, even
>> though it has no implementation of its own to describe, nonetheless
>> describes its implementations.
>
> I agree to everything you wrote except the word �but�,
> because this �but� seems to imply some sort of contradiction
> to something I wrote, but I do not see such a contradiction.

Then I must have misunderstood what you meant by emphasizing
"/interfaces/" and "/abstract/ methods." It seemed to me you saw
some kind of problem applying a contract to a method lacking a
concrete implementation, and I offered examples. Sorry if I've
not grasped your intent.

--
Eric Sosman
esosman(a)ieee-dot-org.invalid
First  |  Prev  | 
Pages: 1 2 3
Prev: logging into site using form validation http components
Next: Windows priorities with runtime.exec