• =?ISO-8859-1?Q?Sigbj=F8rn_Lund_Olsen?= (69/71) Jun 13 2004 This is one of my pet peeves with D. As far as I can logically reason,
• The Dr ... who? (4/72) Jun 13 2004 Count me in as one who wants to hear from big-W on this. I think you may...
• Sam McCall (5/12) Jun 13 2004 Yes, that makes perfect sense. I remember reading some of the phobos
• Mike Swieton (9/12) Jun 13 2004 This has come up before, and I'll second it again: DbC is *broken* if a
• =?ISO-8859-1?Q?Sigbj=F8rn_Lund_Olsen?= (5/15) Jun 14 2004 It'll come up again too, if it isn't implemented. Once every month or

=?ISO-8859-1?Q?Sigbj=F8rn_Lund_Olsen?= <sigbjorn lundolsen.net> writes:

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

"The Dr ... who?" <thedr who.com> writes:

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

Sam McCall <tunah.d tunah.net> writes:

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

Mike Swieton <mike swieton.net> writes:

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"

=?ISO-8859-1?Q?Sigbj=F8rn_Lund_Olsen?= <sigbjorn lundolsen.net> writes:

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