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.
