Proposal for telling an implementation what adjacency info an app/service needs

[Carl Ollivier-Gooch]

Tim Tautges wrote:
> There are cases where there will be variations in capabilities between 
> implementations, without there being enough commonality to justify 
> binding in the API.  The easiest example is load and save options.  In 
> that case, an application must either ifdef directly to the 
> implementation's syntax, or use a string option and test the return 
> value of the function.  Either way the application will need to handle 
> the case where the capability isn't available.  With options, the code 
> is cleaner and there's a middle ground of possibly ignoring the option.

Fair enough, although there should probably be feedback about which of 
multiple options have been ignored.

> And, remember, I don't advocate doing this widely, just in a few cases 
> where specialized behavior has far-reaching consequences.  I have 
> several examples that have been encountered already, one of them 
> resulting in bad press for ITAPS (the sparse vs. dense tags thing).

You gotta admit, though, that citing sparse vs. dense tags as an example 
of the need for a string arg doesn't strengthen your case, since that 
one is a binary choice, -and- we're all likely to be happy to take 
advantage of dense storage internally.

Carl

-- 
------------------------------------------------------------------------
Dr. Carl Ollivier-Gooch, P.Eng.                   Voice: +1-604-822-1854
Associate Professor                                 Fax: +1-604-822-2403
Department of Mechanical Engineering             email: cfog at mech.ubc.ca
University of British Columbia              http://www.mech.ubc.ca/~cfog
Vancouver, BC  V6T 1Z4                  http://tetra.mech.ubc.ca/ANSLab/
------------------------------------------------------------------------