> On Apr 14, 2019, at 6:30 PM, Martin Frb <laza...@mfriebe.de> wrote:
>
> I would actually argue that it is infinitely more important to check for nil
> after MakeThing. (Unless I know for sure it is not needed: proof, docs)
>
> Assuming (taking the danger of doing so) both do what there name indicates,
> then:
> - If I forget to check after FindThing, it is likely to cause an error very
> soon, and most probably while I am testing myself.
> - If I forget it after MakeThing, it may be very rare to cause an error. It
> will likely pass my tests, and cause a customer of mine some stress.
I understand all your concerns over not wanting to use this so I would suggest
to avoid it (we all feel that way about certain features). Since no-one thinks
this is a good idea I’ll forget about because it’s not that important anyways.
Waiting for nullable types is maybe a better option anyways and those are in
the pipeline via default properties.
What Sven brought up is more immediately useful anyways and I can think of many
times I have the mandatory top part of the function that checks to make sure
parameters are valid. Formalizing this process would be a smart thing I think.
If you don’t agree, then don’t use it. ;)
That’s what I read from the link posted. As for the “ensure” block now that I
don’t see as a pattern that I can recognize. Any real world examples of this?
Here’s what I imagine that would look like:
procedure CreateHero (name: string; hp: integer);
requires
name <> '';
(hp > 0) and (hp < 100);
begin
// compilers parses the conditions and inserts as if statements:
// if name <> ‘’ then
// assert(‘condition "name <> ‘'" for CreateHero failed’);
// if (hp > 0) and (hp < 100) then
// assert(‘condition "(hp > 0) and (hp < 100)" for CreateHero failed);
end;
Pretty simple right?
Regards,
Ryan Joseph
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
