Proposal for Requiring Save/Restore of Sets and Tags

[Jason Kraftcheck]

On 10/21/2010 12:55 PM, Carl Ollivier-Gooch wrote:

> 
> Look, having checks like "does this entity have this tag on it" is  very
> useful for debugging mode (I presume we can all agree to that?).  In
> fact, we mandate that implementations will return an error for many of
> these things.  This is much more than a matter of passing the compliance
> tests, it's a debugging aid for programmers using the API.  However, in
> the interests of efficiency, we don't (as I understand the current state
> of things, anyway) require that all implementations will do all (or any)
> of these checks in production mode.
> 
> As for differences between debug and production code, a sensible rule of
> thumb is to execute all of the production code in debug mode and just
> turn off checking for production.  This makes it so the production code
> is actually believably correct.  That doesn't mean you can't make more
> changes than that, but it's probably not really wise.
> 

These are laudable design and implementation goals.  What I question is
whether or not they belong in a discussion of the API specification.  These
goals could be met in other ways.  For example, rather than providing a
developer with two different MOAB iMesh builds, one for production and one
for testing, said developer could just do their testing with a build of the
reference implementation.  Why should our implementation choice in this
matter have to be a concern for the iMesh API specification?


> And for this particular case, the test --- though possibly expensive ---
> is trivial to code, and surround with an #ifdef so that it gets built
> conditionally. 

Maintenance?  Testing?

> So the argument of burden of writing testing code isn't
> a strong one here.
> 

It really wouldn't much work for us to write such a test, but I question the
advisability of this whole approach to conformance testing.  As I said in a
different message, I think that targeting a specific build variation at the
conformance tests is a slippery slope that is better avoided.  We should
focus primarily on ensuring that correct, spec-conforming applications work
with all implementations.  Providing aids to catch non-conforming
applications is more of an implementation detail.

While I agree that to some extent some handling of incorrect applications
should be part of the standard I think that where you choose to draw that
line is a little too strict.  And there definitely is a line.  Consider some
rather poor code that I once wrote in Mesquite that used an iterator to
iterate over all vertices in the mesh and add them one at a time to an
entity set.  This worked fine on MOAB but was completely unusable on FMDB
(at the time, this was several years ago) because adding a single vertex to
a set was O(n) for FMDB.

And none of this touches on the other issue.  We don't want to prohibit
cyclical relations in MOAB.

- jason