On Jun 3, 8:40 pm, Joachim Durchholz
durchholz.org> wrote:> Rüdiger Klaehn schrieb:
>
>> C# does not support pre- and postconditions. But we are planning to
>> use debug assertions instead. I am not a big fan of language level
>> support for pre- and postconditions anyway.
>
> I can say from personal practice that language-supported preconditions
> and postconditions can give invaluable help:
>
> * They help catch errors before they start to propagate. (That's what
> assertions do, too.)
> * They document your code, in a conciseness that's unattainable
> otherwise. (Assertions are worse. Any doctool won't easily know which
> assertions are just paranoia and which are documenting a precondition or
> postcondition. Could be handled via conventions for the doctool, of
> course; I see it rarely done though, for whatever reason.)
> * They nudge programmers towards better code: writing sloppy code means
> you have to write more preconditions to delinate the boundaries within
> which is will work, which in turn means that not only you lose the
> advantages of being sloppy (you're forced to write more preconditions),
> you also get to see the consequences of your sloppiness. (With
> assertions, you'd need a doctool-based culture of documenting your
> code's preconditions and postconditions. Usually fails because not
> properly supported by the doctool.)
> * In an OO context, I found them to be one of the sharpest tools
> available to discriminate what exactly breaks a subtyping relationship:
> no more handwaving and arguing what "programmers would expect the
> subclass here", but simply stating "the subtype does not guarantee
> postcondition foo in such-and-those conditions" and everybody can verify
> this immediately (saves *hours* of fruitless discussion). (Same as
> previous point: few if any projects properly document assumptions on
> preconditions.)
>
> The main difference between debug assertions and pre/postcondition
> checking is that pre/postconditions can be considered part of a
> function's call interface, just as important as parameter and result types.
> In fact parameter and result type declarations are just a special case
> of pre/postcondition, automatically validated at compile time.
>
I am not opposed to the concept of pre- and postconditions per se. I
just do not think that it is good language design to have a little
sublanguage just to describe pre- and postconditions.
Given a language with a sufficiently powerful type system, it should
be possible to express pre- and postconditions using the type system.
For a simple example: when a function may not return null, define the
return type in such a way that null is not a valid value. If a
function expects two parameters a and b where a<=b, define a type
OrderedPair or something to express that.
Of course most mainstream languages have relatively primitive type
systems that make it very hard to express pre- and postconditions that
way.
>> Functional programming in PHP. Never heard of that before.
>
> Me neither. Actually I built everything myself.
> It turned out to be surprisingly simple to implement, less than 20 lines
> of code :-)
>
>> But why
>
>> not: functional programming is not bound to a specific language.
>
> Well, it's still a far cry from the Real Thing.
>
C# is quite a bit closer to a functional language than php, but it is
still quite limited. But in the real world, you sometimes have to live
with these inconveniences.
I will have to implement some interesting hacks in C# to make a
functional style possible for the other project participants.
For example, I implemented something like implicit world passing using
a thread-local "world state". That way the other project participants
can use property setters and under the hood it is still fully
functional and thread-safe.
In a way, it is an interesting challenge to work around the
limitations of a language that way.
> Regards,
> Jo
Regards,
Rüdiger
