digitalmars.D.learn - How do I use in contract with interface?
- Dr. Assembly (23/23) Nov 15 2017 I'm learning to use interface with contracts. In below code, in
- Dr. Assembly (4/4) Nov 15 2017 out(result) {}
- Steven Schveighoffer (16/43) Nov 15 2017 Not going to defend these design decisions, but according to
- Jonathan M Davis (18/54) Nov 15 2017 Well, the rules do make sense when you consider that it can make sense f...
- Steven Schveighoffer (8/20) Nov 15 2017 Loosening does make sense, and I'm not opposed to it.
- Steven Schveighoffer (5/10) Nov 15 2017 I would bet money that at least 50% of the time contract inheritance is
- Jonathan M Davis (7/16) Nov 15 2017 I expect so. When the issue comes up, I frequently have to either think ...
- Jonathan M Davis (34/57) Nov 15 2017 Okay. When inheritance gets involved, contracts get a bit special. If yo...
- Steven Schveighoffer (8/13) Nov 15 2017 Just tested this, and actually, if you put no contract on an interface
- Jonathan M Davis (15/28) Nov 15 2017 The issue is that if _any_ in contract passes, then they all pass, and t...
I'm learning to use interface with contracts. In below code, in
isn't being "called". Can someone point out why? what am I doing
wrong?
void main() {
C c = new C();
writeln(c.foo(1));
}
interface I
{
int foo(int i)
in { assert(i > 2); }
out (result) { assert(result != 0); }
void baa();
}
class C : I
{
int foo(int i) {
return i * 2;
}
void baa() {
writeln("Hello!");
}
}
Nov 15 2017
Dr. Assembly <netorib94 gmail.com>
out(result) {}
run fine, if foo() return 0, an exception is throw by assert()
but in doesn't work. I don't know what I'm missing. It' my first
time using contracts
Nov 15 2017
On 11/15/17 9:43 AM, Dr. Assembly wrote:
I'm learning to use interface with contracts. In below code, in isn't
being "called". Can someone point out why? what am I doing wrong?
void main() {
C c = new C();
writeln(c.foo(1));
}
interface I
{
int foo(int i)
in { assert(i > 2); }
out (result) { assert(result != 0); }
void baa();
}
class C : I
{
int foo(int i) {
return i * 2;
}
void baa() {
writeln("Hello!");
}
}
Not going to defend these design decisions, but according to
https://dlang.org/spec/contracts.html#in_out_inheritance:
1. If a function in a derived class overrides a function in its super
class, then only one of the in contracts of the function and its base
functions must be satisfied. Overriding functions then becomes a process
of loosening the in contracts.
2. A function without an in contract means that any values of the
function parameters are allowed. This implies that if any function in an
inheritance hierarchy has no in contract, then in contracts on functions
overriding it have no useful effect.
So simply overriding a function and specifying no in contract cancels
all in contracts.
I don't think there's a way to specify inheriting the in contract. I
believe the only correct way to do this is to repeat the base's in contract.
-Steve
Nov 15 2017
On Wednesday, November 15, 2017 10:14:32 Steven Schveighoffer via Digitalmars-d-learn wrote:On 11/15/17 9:43 AM, Dr. Assembly wrote:Well, the rules do make sense when you consider that it can make sense for a function to allow arguments that the base class didn't. The in contract is essentially saying what the function can validly operate on, and there's no reason why a derived class couldn't work with more values than the base class could. So, the loosening makes sense when you think about it. It just means that if you're trying to have a contract that you put in one place and then gets reused rather than having to repeat it in each derived class, then in contracts don't really work. For that, it makes more sense to use NVI so that the in contract is on the public base class or interface function, and the protected, derived functions that the public function calls then don't actually have any in contracts. Either way, I don't think that many would argue that the &&ing of the out contracts is problematic. Regardless, the rules that we have come from languages that are far more into contract rules than we are. So, it's not like we made them up. - Jonathan M DavisI'm learning to use interface with contracts. In below code, in isn't being "called". Can someone point out why? what am I doing wrong? void main() { C c = new C(); writeln(c.foo(1)); } interface I { int foo(int i) in { assert(i > 2); } out (result) { assert(result != 0); } void baa(); } class C : I { int foo(int i) { return i * 2; } void baa() { writeln("Hello!"); } }Not going to defend these design decisions, but according to https://dlang.org/spec/contracts.html#in_out_inheritance:
Nov 15 2017
On 11/15/17 10:39 AM, Jonathan M Davis wrote:Well, the rules do make sense when you consider that it can make sense for a function to allow arguments that the base class didn't. The in contract is essentially saying what the function can validly operate on, and there's no reason why a derived class couldn't work with more values than the base class could. So, the loosening makes sense when you think about it. It just means that if you're trying to have a contract that you put in one place and then gets reused rather than having to repeat it in each derived class, then in contracts don't really work. For that, it makes more sense to use NVI so that the in contract is on the public base class or interface function, and the protected, derived functions that the public function calls then don't actually have any in contracts.Loosening does make sense, and I'm not opposed to it. But what doesn't make a lot of sense is the inability to declare the inheritance of the current in-contract situation. If you have a complex contract, then having to repeat it on every class seems unnecessarily verbose. It's very easy to just say `in {}` if you now can accept all possible parameters. The opposite is not as easy. -Steve
Nov 15 2017
On 11/15/17 11:19 AM, Steven Schveighoffer wrote:
But what doesn't make a lot of sense is the inability to declare the
inheritance of the current in-contract situation. If you have a complex
contract, then having to repeat it on every class seems unnecessarily
verbose. It's very easy to just say `in {}` if you now can accept all
possible parameters. The opposite is not as easy.
I would bet money that at least 50% of the time contract inheritance is
used, people use base contracts to mean THE contract, and don't put
contracts on derived functions, and they don't even realize it.
-Steve
Nov 15 2017
On Wednesday, November 15, 2017 11:21:16 Steven Schveighoffer via Digitalmars-d-learn wrote:On 11/15/17 11:19 AM, Steven Schveighoffer wrote:I expect so. When the issue comes up, I frequently have to either think it through or look up the rules if I want to remember what they are. But honestly, I've given up on using contracts in general, and I rarely use classes, so it's not something that I usually think about. - Jonathan M DavisBut what doesn't make a lot of sense is the inability to declare the inheritance of the current in-contract situation. If you have a complex contract, then having to repeat it on every class seems unnecessarily verbose. It's very easy to just say `in {}` if you now can accept all possible parameters. The opposite is not as easy.I would bet money that at least 50% of the time contract inheritance is used, people use base contracts to mean THE contract, and don't put contracts on derived functions, and they don't even realize it.
Nov 15 2017
On Wednesday, November 15, 2017 14:43:33 Dr. Assembly via Digitalmars-d-
learn wrote:
I'm learning to use interface with contracts. In below code, in
isn't being "called". Can someone point out why? what am I doing
wrong?
void main() {
C c = new C();
writeln(c.foo(1));
}
interface I
{
int foo(int i)
in { assert(i > 2); }
out (result) { assert(result != 0); }
void baa();
}
class C : I
{
int foo(int i) {
return i * 2;
}
void baa() {
writeln("Hello!");
}
}
Okay. When inheritance gets involved, contracts get a bit special. If you
had a free function or a struct's member function, things would be simple
enough. The in contract would be run before the function's bode was run, and
the out contract would be run afterwards. If either failed, an AssertError
would be thrown. However, it works a bit differently with classes. To quote
the documentation ( section 23.3: https://dlang.org/spec/contracts.html ):
===========
1. If a function in a derived class overrides a function in its super class,
then only one of the in contracts of the function and its base functions
must be satisfied. Overriding functions then becomes a process of loosening
the in contracts.
2. A function without an in contract means that any values of the function
parameters are allowed. This implies that if any function in an inheritance
hierarchy has no in contract, then in contracts on functions overriding it
have no useful effect.
3. Conversely, all of the out contracts need to be satisfied, so overriding
functions becomes a processes of tightening the out contracts.
===========
So, effectively, in contracts are all ||ed and out contracts are all &&ed,
and the lack of an in contract means that that contract passes. So, if you
don't have an in contract, or if you have an empty one, then all base class
(or interface) contracts are pointless for that derived function. So, in
contracts only really get inherited in the sense that it gives you another
contract that could pass. It really doesn't provide a way to restrict
derived functions. So, it's pointless to put an in contract on an
interface's function unless you're trying to ensure that nothing in derived
contracts is any stricter than that contract, which in practice likely means
that it's pointless to put an in contract on an interface function.
However, out contracts do restrict derived functions, since those are
effectively &&ed together. So, it can make sense to put those are
interfaces.
- Jonathan M Davis
Nov 15 2017
On 11/15/17 10:14 AM, Jonathan M Davis wrote:So, it's pointless to put an in contract on an interface's function unless you're trying to ensure that nothing in derived contracts is any stricter than that contract, which in practice likely means that it's pointless to put an in contract on an interface function.Just tested this, and actually, if you put no contract on an interface function, it negates any contracts on the implementing functions. So there definitely is a use for the in contract on an interface -- if you plan on defining contracts on implementing types. I'm curious why the absence of an in contract disables all other in contracts. I would have expected it to simply have no effect. -Steve
Nov 15 2017
On Wednesday, November 15, 2017 10:33:50 Steven Schveighoffer via Digitalmars-d-learn wrote:On 11/15/17 10:14 AM, Jonathan M Davis wrote:The issue is that if _any_ in contract passes, then they all pass, and the lack of an in contract is the same as a contract that always passes. So, I guess that if you're trying to put contracts on your derived classes, the in contract on the interface function isn't really pointless, but it really doesn't have the desired effect. Basically, once you have any class or interface in the inheritance chain, you have to put in contracts on _all_ of them if you want them to have any effect - and whichever one is the loosest is the one that's going to really matter. All in all, I expect that in most cases, using NVI with an in contract on the public function would be much closer to what folks would be looking for. The way that in contracts work with inheritance makes sense in principle, but it does tend to make them kind of useless in practice. - Jonathan M DavisSo, it's pointless to put an in contract on an interface's function unless you're trying to ensure that nothing in derived contracts is any stricter than that contract, which in practice likely means that it's pointless to put an in contract on an interface function.Just tested this, and actually, if you put no contract on an interface function, it negates any contracts on the implementing functions. So there definitely is a use for the in contract on an interface -- if you plan on defining contracts on implementing types. I'm curious why the absence of an in contract disables all other in contracts. I would have expected it to simply have no effect.
Nov 15 2017