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?

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

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

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

"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.

"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.

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

"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 ;)

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