This is one of my pet peeves with D. As far as I can logically reason, interfaces are not powerful enough as long as it is impossible to define contracts in the interfaces. The entire concept of an interface is to constrain implementors to something 'externally defined' - the logical extension to 'vanilla' interfaces in a language supporting and advocating the use of Design-by-Contract, is to support contracts in interfaces.

Using the newest DMD, I can compile interfaces with contracts without complaint, but the contracts are actually ignored. Here's the example source:

// begin interface_contracts.d

interface Foo
{
	int aFunction(ubyte firstArg, int secondArg)
	in
	{
		assert(firstArg <= 100);
	}
	out (result)
	{
		assert(result <= secondArg);
	};
	
}

class Bar : Foo
{
	int aFunction(ubyte firstArg, int secondArg)
	/* uncomment to implement contracts in class
	in
	{
		assert(firstArg <= 100);
	}
	out (result)
	{
		assert(result <= secondArg);
	}
	*/	
	body
	{
		double temp = cast(double) firstArg / 100;
		int result = cast(int) ((cast(double) secondArg) * temp);
		return result;
	}
}

int main(char[][] args)
{
	Bar aClass = new Bar;
	
	printf("%i\n", aClass.aFunction(10, 123456));
	printf("%i\n", aClass.aFunction(50, 123456));
	printf("%i\n", aClass.aFunction(200, 123456));
	
	return 0;
}

// end interface_contracts.d

In the version with the contract in Bar's aFunction commented out, this is the output:

>interface_contracts
12345
61728
246912

As you can see, the assertion that firstArg should be less or equal to a hundred, and that the result should be smaller or equal to secondArg, is completely ignored. In the version where the contract is defined in Bar, the contract works, giving us this as the output:

>interface_contracts
12345
61728
Error: AssertError Failure interface_contracts.d(19)

Cheers,
Sigbjørn Lund Olsen

Count me in as one who wants to hear from big-W on this. I think you may have a good case.

"Sigbjørn Lund Olsen" <sigbjorn@lundolsen.net> wrote in message news:cahsmr$8l0$1@digitaldaemon.com...
> This is one of my pet peeves with D. As far as I can logically reason, interfaces are not powerful enough as long as it is impossible to define contracts in the interfaces. The entire concept of an interface is to constrain implementors to something 'externally defined' - the logical extension to 'vanilla' interfaces in a language supporting and advocating the use of Design-by-Contract, is to support contracts in interfaces.
>
> Using the newest DMD, I can compile interfaces with contracts without complaint, but the contracts are actually ignored. Here's the example source:
>
> // begin interface_contracts.d
>
> interface Foo
> {
> int aFunction(ubyte firstArg, int secondArg)
> in
> {
> assert(firstArg <= 100);
> }
> out (result)
> {
> assert(result <= secondArg);
> };
>
> }
>
> class Bar : Foo
> {
> int aFunction(ubyte firstArg, int secondArg)
> /* uncomment to implement contracts in class
> in
> {
> assert(firstArg <= 100);
> }
> out (result)
> {
> assert(result <= secondArg);
> }
> */
> body
> {
> double temp = cast(double) firstArg / 100;
> int result = cast(int) ((cast(double) secondArg) * temp);
> return result;
> }
> }
>
> int main(char[][] args)
> {
> Bar aClass = new Bar;
>
> printf("%i\n", aClass.aFunction(10, 123456));
> printf("%i\n", aClass.aFunction(50, 123456));
> printf("%i\n", aClass.aFunction(200, 123456));
>
> return 0;
> }
>
> // end interface_contracts.d
>
> In the version with the contract in Bar's aFunction commented out, this is the output:
>
>  >interface_contracts
> 12345
> 61728
> 246912
>
> As you can see, the assertion that firstArg should be less or equal to a hundred, and that the result should be smaller or equal to secondArg, is completely ignored. In the version where the contract is defined in Bar, the contract works, giving us this as the output:
>
>  >interface_contracts
> 12345
> 61728
> Error: AssertError Failure interface_contracts.d(19)
>
> Cheers,
> Sigbjørn Lund Olsen

Sigbjørn Lund Olsen wrote:

> This is one of my pet peeves with D. As far as I can logically reason, interfaces are not powerful enough as long as it is impossible to define contracts in the interfaces. The entire concept of an interface is to constrain implementors to something 'externally defined' - the logical extension to 'vanilla' interfaces in a language supporting and advocating the use of Design-by-Contract, is to support contracts in interfaces.

Yes, that makes perfect sense. I remember reading some of the phobos code that had comments to the effect that contracts should be/were going to be inherited through the class hierarchy, not sure if that ever happened.
Sam

On Sun, 13 Jun 2004 17:43:39 +0200, Sigbjørn Lund Olsen wrote:
> This is one of my pet peeves with D. As far as I can logically reason, interfaces are not powerful enough as long as it is impossible to define contracts in the interfaces. The entire concept of an interface is to

This has come up before, and I'll second it again: DbC is *broken* if a contract cannot be specified on an interface - For what is an interface, if not a contract?

Mike Swieton
__
God made the world and He saw that it was good. Not fair. Not happy. Nor
perfect. Good.
	- Mary Doria Russel, "Children of God"

Mike Swieton wrote:
> On Sun, 13 Jun 2004 17:43:39 +0200, Sigbjørn Lund Olsen wrote:
> 
>>This is one of my pet peeves with D. As far as I can logically reason, interfaces are not powerful enough as long as it is impossible to define contracts in the interfaces. The entire concept of an interface is to 
> 
> 
> This has come up before, and I'll second it again: DbC is *broken* if a
> contract cannot be specified on an interface - For what is an interface, if
> not a contract?

It'll come up again too, if it isn't implemented. Once every month or two. It is, after all, my opinion that Carthage should be burnt.

Cheers,
Sigbjørn Lund Olsen