itaps-parallel Proposal for Requiring Save/Restore of Sets and Tags

[Jason Kraftcheck]

On 10/21/2010 01:30 PM, Carl Ollivier-Gooch wrote:

> 
> Get off the point of conformance testing, as that's a side issue.
> 

I'm not sure that it is.  But I'll try to avoid mentioning it again.

> The -real- issue is that there are internal checks that should be done
> to help API users with debugging.  This is why we return errors.  Yes,
> this is something the compliance tests check for, but that's not why
> they're there.
> 

We return errors when things fail.  That is an obviously well accepted
programming practice.  Failure to return an error flag of some kind when an
operation fails is a bug (regardless of whether or not one is in a "release"
mode.)  That is distinct from helping users with debugging, which should be
an implementation issue.


> And yes, the implementation that's used is practice should be the one
> that's tested.  What I'm saying is -specifically- that the -test- can be
> disabled in production mode.  By this time, presumably the API user has
> code that is functioning properly and all those tests will pass anyway,
> so they're a waste of time.  The only exception, I suppose, would be
> differences in behavior for different input, but those strike me as
> likely to be rare.
> 

If the implementation is unusable in "testing" mode because it is doing some
O(n^2) checking operation then have we really helped the developer?

> I don't know about you, but when I use #ifndef NDEBUG, I -only- put
> things in those blocks that are pure tests with no side effects.  The
> code that produces useful results (i.e., the production code) goes
> outside these.

Is there something you're trying to imply? :)

>  The debug-mode code does a lot of work on the side
> without affecting any output.  That's the programming style I think
> makes sense here, too:  write production code and decorate it with the
> necessary checks, some or all of which will be disabled in production
> code, without affecting what the production code does.
> 

That's a great coding practice.  However, I a) don't think it is appropriate
for this particular case and b) don't see why you consider it part of the
iMesh API rather than an implementation choice that we made.

> So no, I don't think this is the beginning of a slippery slope.  And I
> certainly disagree that there's anything involved that's focused
> specifically at compliance tests.
> 

So if users never enable our "strict conformance" mode and we don't
otherwise test for this does it really matter that the compliance test
checked this and that our implementation passed?

- jason