www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DBC and the Pragmatic Programmer

reply pragma <pragma_member pathlink.com> writes:
No, this post isn't about myself.  Rather, its about the _book_ and D.

If you don't own "The Pragmatic Programmer" already, I highly reccomend it.
IMO, its the kind of text that transcends all of your Booch, Oriely and Knuth
books put together; much like the way "Design Patterns" does.  I promise, this
won't wind up in that box in the attic along with your "C64 Programmer's
Reference" and "Teach Yourself C++ in 21 Days"!

I was re-reading this book while on break today, and I noticed how D directly
supports the spirit entire DBC chapter.  (My copy was printed in April of 2000,
so D's not even mentioned)  The relationship is sriking, if not entirely
deliberate. Overall, I found myself rewriting the c++ samples in D (in my head)
and was pleased at how the language handles things with so little effort.
Thanks Walter!

Anyway, it really sparked my imagination, and how to further improve D's
handling of DBC philosophies in general.

I'd like to propose two things:

- in/out invariants for *any* block of code.  This would include foreach, while,
for as well as anonymous blocks of functions (anything between curly brackets).

- a 'release' keyword that could be used to force compilation of any statment in
release mode that would otherwise be thrown out.  This especially applies to
'assert', 'invariant' and on the function level to force in/out DBC. 

The latter, to me, really feels like it fills a void in D's current
specification.  Aside from compiling release and debug objects into the same
executable, there is no way to take advantage of D's dbc constructs outside of a
debug build.

Also, it would be nice to be able to enable/disable array bounds checking
independently of debug/release builds.  Much like invariants and in/out
contracts, it is a program-altering behavior and may not always be cleanly
separable from one's code for the sake of performance. 

Eric Anderton -- at -- yahoo
Oct 21 2004
parent "Matthew" <admin.hat stlsoft.dot.org> writes:
Weird coincidence

I was reviewing some DbC / PwC stuff for a friend yesterday, and got out
PragProg and reread the DbC chapter. It, more
than anything else I've read, tallies with my beliefs on contracts. Marvellous
stuff.

(Some months ago I wrongly attributed the "invalid programs must die"
philosophy to Meyer's book. I now realise it was
PragProg.)

Anyone that doesn't have it, should buy. There are many chapters, on a
bewildering variety of subjects, and they are
almost all, IIRC, as good as the contracts one.

As for your suggestions, I cannot say I disagree. Programmer knows best, after
all.

"pragma" <pragma_member pathlink.com> wrote in message
news:cl974d$15fe$1 digitaldaemon.com...
 No, this post isn't about myself.  Rather, its about the _book_ and D.

 If you don't own "The Pragmatic Programmer" already, I highly reccomend it.
 IMO, its the kind of text that transcends all of your Booch, Oriely and Knuth
 books put together; much like the way "Design Patterns" does.  I promise, this
 won't wind up in that box in the attic along with your "C64 Programmer's
 Reference" and "Teach Yourself C++ in 21 Days"!

 I was re-reading this book while on break today, and I noticed how D directly
 supports the spirit entire DBC chapter.  (My copy was printed in April of 2000,
 so D's not even mentioned)  The relationship is sriking, if not entirely
 deliberate. Overall, I found myself rewriting the c++ samples in D (in my head)
 and was pleased at how the language handles things with so little effort.
 Thanks Walter!

 Anyway, it really sparked my imagination, and how to further improve D's
 handling of DBC philosophies in general.

 I'd like to propose two things:

 - in/out invariants for *any* block of code.  This would include foreach,
while,
 for as well as anonymous blocks of functions (anything between curly brackets).

 - a 'release' keyword that could be used to force compilation of any statment
in
 release mode that would otherwise be thrown out.  This especially applies to
 'assert', 'invariant' and on the function level to force in/out DBC.

 The latter, to me, really feels like it fills a void in D's current
 specification.  Aside from compiling release and debug objects into the same
 executable, there is no way to take advantage of D's dbc constructs outside of
a
 debug build.

 Also, it would be nice to be able to enable/disable array bounds checking
 independently of debug/release builds.  Much like invariants and in/out
 contracts, it is a program-altering behavior and may not always be cleanly
 separable from one's code for the sake of performance.

 Eric Anderton -- at -- yahoo
Oct 21 2004