• =?ISO-8859-1?Q?Sigbj=F8rn_Lund_Olsen?= (54/56) Mar 21 2004 I checked something out today: Can contracts be defined in an interface....
• =?ISO-8859-1?Q?Sigbj=F8rn_Lund_Olsen?= (8/9) Mar 21 2004 And may I motion that some solution has to be found to the implicit
• Walter (3/59) Mar 23 2004 I'm not sure what the right answer is here.
• Mike Swieton (14/15) Mar 23 2004 I vote that interfaces should be able to have contracts which would be

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

I checked something out today: Can contracts be defined in an interface. 
  I was a little surprised at what I found out. Contracts in interfaces 
will compile without a mutter (though you need a semicolon after the 
in{}out{} blocks in interfaces), but will not actually be compiled into 
the code.

Test code with contracts in interfaces:

// START
interface test
{
	uint test(uint number)
	in
	{
		assert(number >= 0);
		assert(number <= 1000);
	}
	out (result)
	{
		assert(result >= 0);
		assert(result >= 10);
	};
}

class TestImpl : test
{
	uint test(uint number)
	body
	{
		return(number / 100);
	}
}

int main()
{
	TestImpl foobar = new TestImpl;
	printf("%d -> %d\n", 41, foobar.test(41));
	printf("%d -> %d\n", 441, foobar.test(441));
	printf("%d -> %d\n", 1241, foobar.test(1241));
	printf("%d -> %d\n", -41, foobar.test(-41));
	printf("%d -> %d\n", 500, foobar.test(500));

	return 0;
}
// END

This returns the following:

dbcinterfaces

41 -> 0
441 -> 4
1241 -> 12
-41 -> 42949672
500 -> 5

Now, by copy pasting the contract into the implemtation, you get the 
expected result:

dbcinterfaces

Error: AssertError Failure dbcinterfaces.d(27)

To me it would seem intuitive if it were possible to define contracts 
within interfaces, so I'm wondering if there's any reason why this is 
the way it is?

Cheers,
Sigbjørn Lund Olsen

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

Sigbjørn Lund Olsen wrote:

 -41 -> 42949672

And may I motion that some solution has to be found to the implicit 
conversion 'problem'? (atm I'm thinking I'll just sprinkle every 
function in contract with a static assert with typeof to do the job for 
me, but that's still another thing I have to remember rather than have 
the language do it, or be capable of doing it, for me)

Cheers,
Sigbjørn Lund Olsen

"Walter" <walter digitalmars.com> writes:

I'm not sure what the right answer is here.

"Sigbjørn Lund Olsen" <sigbjorn lundolsen.net> wrote in message
news:c3josp$r3a$1 digitaldaemon.com...
 I checked something out today: Can contracts be defined in an interface.
   I was a little surprised at what I found out. Contracts in interfaces
 will compile without a mutter (though you need a semicolon after the
 in{}out{} blocks in interfaces), but will not actually be compiled into
 the code.

 Test code with contracts in interfaces:

 // START
 interface test
 {
 uint test(uint number)
 in
 {
 assert(number >= 0);
 assert(number <= 1000);
 }
 out (result)
 {
 assert(result >= 0);
 assert(result >= 10);
 };
 }

 class TestImpl : test
 {
 uint test(uint number)
 body
 {
 return(number / 100);
 }
 }

 int main()
 {
 TestImpl foobar = new TestImpl;
 printf("%d -> %d\n", 41, foobar.test(41));
 printf("%d -> %d\n", 441, foobar.test(441));
 printf("%d -> %d\n", 1241, foobar.test(1241));
 printf("%d -> %d\n", -41, foobar.test(-41));
 printf("%d -> %d\n", 500, foobar.test(500));

 return 0;
 }
 // END

 This returns the following:

  >dbcinterfaces
 41 -> 0
 441 -> 4
 1241 -> 12
 -41 -> 42949672
 500 -> 5

 Now, by copy pasting the contract into the implemtation, you get the
 expected result:

  >dbcinterfaces
 Error: AssertError Failure dbcinterfaces.d(27)

 To me it would seem intuitive if it were possible to define contracts
 within interfaces, so I'm wondering if there's any reason why this is
 the way it is?

 Cheers,
 Sigbjørn Lund Olsen

Mike Swieton <mike swieton.net> writes:

On Tue, 23 Mar 2004 16:59:55 -0800, Walter wrote:

 I'm not sure what the right answer is here.

I vote that interfaces should be able to have contracts which would be
checked on all implementing methods. I think it would be tremendously
useful to be able to explicitly specify the contract like this.

An example: many standard Java APIs use interfaces (collections, for
example). The contracts on these methods is spelled out explicitly in the
documentation but there is no enforcement.

An interface usually has a contract to go with it, even if it's not made
explicit.

Mike Swieton
__
Anyone who attempts to generate random numbers by deterministic means is, of
course, living in a state of sin.
	- John Von Neumann