View mode: basic / threaded / horizontal-split · Log in · Help
May 31, 2005
Re: DbC vs. argument checking
Derek Parnell wrote:
> I tend to place the validation code in the release edition that is to
> undergo User Acceptance testing. If, and only if, the user objects to the
> performance, I explain the ramifications of removing it and then let the
> user decide. The corresponding User Requirements specification is updated
> accordingly.

Ok, that sound very professional. You obviously work for a software 
company :)

Personally I had in mind that I would put argument validation in 
contracts and profile the DbC enabled version against the release 
version. If the difference turned out to be negligible, I would ship the 
DbC enabled version. And I would still be able to throw in an ultra-fast 
release build if necessary.

The downside with this strategy is that compiling with the release 
switch should be prevented and the reason for this documented. Also (as 
I've stated numerous times) I'm not satisfied at all with the level of 
information contained in AssertErrors.

Somehow I would *very much* like to use the built-in DbC in D for all 
purposes. Wasn't the whole point of in, out and invariant blocks to 
reduce the clutter of argument/other validation code in the function bodies?
May 31, 2005
Re: DbC vs. argument checking
On Tue, 31 May 2005 11:31:35 +0300, Niko Korhonen wrote:

> Derek Parnell wrote:
>  > I tend to place the validation code in the release edition that is to
>  > undergo User Acceptance testing. If, and only if, the user objects to the
>  > performance, I explain the ramifications of removing it and then let the
>  > user decide. The corresponding User Requirements specification is updated
>  > accordingly.
> 
> Ok, that sound very professional. You obviously work for a software 
> company :)
> 
> Personally I had in mind that I would put argument validation in 
> contracts and profile the DbC enabled version against the release 
> version. If the difference turned out to be negligible, I would ship the 
> DbC enabled version. And I would still be able to throw in an ultra-fast 
> release build if necessary.
> 
> The downside with this strategy is that compiling with the release 
> switch should be prevented and the reason for this documented. Also (as 
> I've stated numerous times) I'm not satisfied at all with the level of 
> information contained in AssertErrors.
> 
> Somehow I would *very much* like to use the built-in DbC in D for all 
> purposes. Wasn't the whole point of in, out and invariant blocks to 
> reduce the clutter of argument/other validation code in the function bodies?

Another "improvement" might be to allow the developer better control of
what "-release" switch chops out. Let the current syntax "-release" work as
it does now, but also allow qualifications such as "-keep=in,assert" to
retain 'in' blocks and 'asserts' even if -release is specified.

-- 
Derek Parnell
Melbourne, Australia
31/05/2005 9:22:46 PM
May 31, 2005
Re: DbC vs. argument checking
On Tue, 31 May 2005 11:31:35 +0300, Niko Korhonen wrote:

> Derek Parnell wrote:
>  > I tend to place the validation code in the release edition that is to
>  > undergo User Acceptance testing. If, and only if, the user objects to the
>  > performance, I explain the ramifications of removing it and then let the
>  > user decide. The corresponding User Requirements specification is updated
>  > accordingly.
> 
> Ok, that sound very professional. You obviously work for a software 
> company :)

Yes I do. 

-- 
Derek Parnell
Technical Product Manager - RBX, PBX
Admerex Solutions Pty Ltd
http://www.admerex.com
Melbourne, AUSTRALIA
31/05/2005 9:26:31 PM
May 31, 2005
Re: DbC vs. argument checking
Argument checking sounds like the first valid use of value-based function
overloading (read on the digitalmars.D NG) I've heard yet.  Default
implementation of the function would simply throw argument exceptions, while
more specific implementations on values and ranges would allow the data to be
passed through.  Example:

// base function
int test(int a, int b is 0 .. 5) {
throw new ArgumentException("a is out of range");
}

// a and b are in correct ranges
int test(int a is 5 .. 10, b is 0 .. 5) {
return a + b;
}

Regards,
James Dunne
May 31, 2005
Re: DbC vs. argument checking
"Niko Korhonen" <niktheblak@hotmail.com> wrote in message 
news:d7gvq6$skc$1@digitaldaemon.com...
> Jarrett Billingsley wrote:
>> I suppose the argument for that is that if your program runs fine in 
>> debug, and contracts are always met, then it'll run fine in release mode.
>
> And what about the situation where incorrect parameters are passed to the 
> release mode program, either by accident or by purposeful hacking?
>
> I just /can't/ throw away the life jacket of vigorous argument checking 
> when delivering a program/library, no matter how well it ran in test 
> environment!

I'm not saying I agree with that argument; I'm just saying that that's the 
reasoning behind it.  If you really really need argument checking on 
something - make it a test in the actual function.

And if someone's hacking your program, there's nothing stopping them from 
skipping the argument validation code ;)

>> Again, I think the contracts are really only meant to be used in the 
>> debugging phase.  You can use them, but only when you're in the process 
>> of writing your program.
>
> Isn't it a rather heavy feature just for dev phase debugging?

It's not really a heavy feature.  If you think about it, you could write an 
"in" block as

void fork()
{
   debug
   {
       // same as an in block
   }

   // same as a body block
}

It's just a debug block that puts its statements at the beginning of the 
function.  As such, you only put things in the "in" block that you only want 
(need?) to test in the debug phase.

Besides, any features to help with debugging are gratefully accepted, no 
matter how heavy-duty they are.  The more heavy-duty they are, usually the 
more gratefully they are accepted ;)

>> Additionally, you asked how to deliver a good API.  Well, many libraries 
>> I've seen come with two versions - debug and release.  That way, the 
>> debug version of the API has all the contracts and parameter validation, 
>> while the release code has all (or most) of that removed for speed.
>
> That might work and might also be practical. But somehow I just don't like 
> it. Besides, in some situations switching a library on the fly when trying 
> to hunt down a mysterious problem might not be practical at all.

Well, there isn't much alternative.  You could distibute the source to your 
library that has debug statements / DbC in it, but then you'd be 
distributing the source.  Besides - switching between debug and release 
versions of the library would require one small change in the command line. 
And better yet, if you're using an IDE, that's all handled for you with 
Debug and Release build configurations.
May 31, 2005
Re: DbC vs. argument checking
"James Dunne" <james.jdunne@gmail.com> wrote in message 
news:d7i23j$23h9$1@digitaldaemon.com...
> Argument checking sounds like the first valid use of value-based function
> overloading (read on the digitalmars.D NG) I've heard yet.  Default
> implementation of the function would simply throw argument exceptions, 
> while
> more specific implementations on values and ranges would allow the data to 
> be
> passed through.  Example:
>
> // base function
> int test(int a, int b is 0 .. 5) {
> throw new ArgumentException("a is out of range");
> }
>
> // a and b are in correct ranges
> int test(int a is 5 .. 10, b is 0 .. 5) {
> return a + b;
> }
>
> Regards,
> James Dunne

That seems pretty verbose for something that would be more succinctly (and 
readably) be written as a regular param check.
May 31, 2005
Re: DbC vs. argument checking
On Tue, 31 May 2005 18:27:17 -0400, Jarrett Billingsley wrote:


> Besides - switching between debug and release 
> versions of the library would require one small change in the command line. 
> And better yet, if you're using an IDE, that's all handled for you with 
> Debug and Release build configurations.

And if using the Build utility with the default configuration file, just
add +dbg or +prod to command line....

Debugging edition:
 build myapp +dbg

Release edition:
 build myapp +prod

-- 
Derek Parnell
Melbourne, Australia
Download BUILD from ...
http://www.dsource.org/projects/build/ v2.08 released 29/May/2005

http://www.prowiki.org/wiki4d/wiki.cgi?FrontPage

1/06/2005 9:25:10 AM
June 01, 2005
Re: DbC vs. argument checking
"Derek Parnell" <derek@psych.ward> wrote in message 
news:pziqig2d5vj7.13gea7jfjcyqn.dlg@40tude.net...
> And if using the Build utility with the default configuration file, just
> add +dbg or +prod to command line....
>
> Debugging edition:
>  build myapp +dbg
>
> Release edition:
>  build myapp +prod

I believe you forgot the <shameless_plug> tags ;)
June 01, 2005
Re: DbC vs. argument checking
On Tue, 31 May 2005 22:27:31 -0400, Jarrett Billingsley wrote:

> "Derek Parnell" <derek@psych.ward> wrote in message 
> news:pziqig2d5vj7.13gea7jfjcyqn.dlg@40tude.net...
>> And if using the Build utility with the default configuration file, just
>> add +dbg or +prod to command line....
>>
>> Debugging edition:
>>  build myapp +dbg
>>
>> Release edition:
>>  build myapp +prod
> 
> I believe you forgot the <shameless_plug> tags ;)

What?! I'm perfect now, eh?  ;-)

I just wish I was collecting royalties or something for it. The project
started as a simple tool for me to use, and I got 'tricked' into supporting
other people's needs too. Oh well, all for the better good (I hope).

And it's been very useful to help me learn D programming.

-- 
Derek Parnell
Melbourne, Australia

*************************************************
<plug category="shameless">
Download BUILD from ...
http://www.dsource.org/projects/build/ v2.08 released 29/May/2005
</plug>
*************************************************

http://www.prowiki.org/wiki4d/wiki.cgi?FrontPage

1/06/2005 12:43:21 PM
Next ›   Last »
1 2
Top | Discussion index | About this forum | D home