digitalmars.D - DBC and the Pragmatic Programmer
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
"Matthew" <admin.hat stlsoft.dot.org> 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