Thoughts about in contract inheritance

Timon Gehr timon.gehr at gmx.ch
Thu Mar 1 08:19:26 PST 2012


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.


More information about the Digitalmars-d mailing list