Am 14.04.2019 um 23:48 schrieb Martin Frb:
As for "documentation". I disagree with the way it is done in oxygen.
But I am not sure I have any good alternative.
For me a class contract (require/ensure) is part of the interface.
So it would have to be like (and similar for plain procedures, no
class) // can be all on one line....
type
TFoo= class
function DoTheFooThing(Foo1, Foo2: TFoo): Tbar;
requires
assigned(Foo1) or assigned(Foo2): 'Need at least 1 foo, for
the connection';
guarantees // better than ensure
assigned(result);
result.KnowsMyFoo = true: 'Connection exists'; // the
=true is redundant
procedure DoTheBar;
end;
So reading this declaration, you immediately know what is valid. And
if custom messages are give, they may tell you way
It is to be noted, that requires and guarantees contain conditions
(expressions), not pascal code. So technically it is ok, that they are
in the interface and not implementation.
If I want something in the implementation, I can use normal "assert"
(which by the way, have often great documenting value)
The problem is that both "require" and "ensure" can check for fields as
well (think of a setter for example or something that changes the
state). Thus you could use a field name that the compiler does not yet
know. So you would need to order your methods in a order dictated by the
compiler due to the method's implementation instead of an order of your
own choosing.
And yes, that would also be a problem with "class invariants", though
there it's more clear if we say that only identifiers can be used that
have been declared before as it's the same with properties and their
setters/getters.
Regards,
Sven
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
