On 29/02/2012 20:45, Timon Gehr wrote:
> On 02/29/2012 09:30 PM, Stewart Gordon wrote:
<snip>
>> But I can see what you really mean: the spec of what inputs to an
>> overridable function are legal and what inputs are illegal is part of
>> the API.
>>
>> Stewart.
>
> An input that is not legal is illegal and vice-versa.

Well, obviously, but what's your point?

Maybe the question is of what's meant by "part of the API".  I'd made out that we were talking about what a user of the library would be right to rely on.  That a given function call is legal normally falls under that category.  But if you call a function, you will call it with legal input, so probably won't care about some other input that is illegal.

Of course, if the function in question admits alternative implementations through virtuality, then you're going to get implementations relying on the restrictions on input, so the illegality of some calls to the function becomes part of the API.  But that doesn't magically render "the fact that a given function call is legal is part of the API" and "the fact that a given function call is illegal is part of the API" logically equivalent statements.

Or does some of your code rely on the fact that a given library class has no method with a given name?

Stewart.

On 03/01/2012 01:49 AM, Stewart Gordon wrote:
> On 29/02/2012 20:45, Timon Gehr wrote:
>> On 02/29/2012 09:30 PM, Stewart Gordon wrote:
> <snip>
>>> But I can see what you really mean: the spec of what inputs to an
>>> overridable function are legal and what inputs are illegal is part of
>>> the API.
>>>
>>> Stewart.
>>
>> An input that is not legal is illegal and vice-versa.
>
> Well, obviously, but what's your point?
>
> Maybe the question is of what's meant by "part of the API". I'd made out
> that we were talking about what a user of the library would be right to
> rely on.

Exactly.

>  That a given function call is legal normally falls under that
> category. But if you call a function, you will call it with legal input,
> so probably won't care about some other input that is illegal.
>
> Of course, if the function in question admits alternative
> implementations through virtuality, then you're going to get
> implementations relying on the restrictions on input, so the illegality
> of some calls to the function becomes part of the API. But that doesn't
> magically render "the fact that a given function call is legal is part
> of the API" and "the fact that a given function call is illegal is part
> of the API" logically equivalent statements.
>

Well, what is part of the API ultimatively depends on what is in the API documentation. If this documentation does not specify the behavior of a function for a certain set of inputs, then it can add suitable behaviors for those inputs to the API documentation later. In case of virtual overridable functions (as in the scenario we are discussing in this thread), the API must specify sufficient and required conditions that clearly identify the function input validity. It is in this case when the two statements are equivalent. In the general case that includes non-overridable functions, they might be different.


> Or does some of your code rely on the fact that a given library class
> has no method with a given name?
>

Most meaningful code that inherits a library class does rely on such a fact.