[MINC-development] ABS and SIGN

[Steve ROBBINS]

On Wed, Jun 18, 2003 at 09:35:01AM +1000, Andrew Janke wrote:
> On Tue, 17 Jun 2003, Steve ROBBINS wrote:
 
> > How about we make "clean up the namespace" a release goal for MINC 1.2?  What
> > needs some thought is providing backward compatibility for clients of the
> > library who do use these symbols.  Mainly the decision is: do we make current
> > users do something special to define the symbols, or do we make future users
> > do something special to get a clean namespace?  Where "something special" is
> > either "#define a symbol" or "#include a different header".
> 
> My suggestion is to break volume_io in the new version and make old programs
> include something such as old_volume_io.h that includes one extra file:
> volume_io/broken_defines.h 

I'm going to cast a vote for the more conservative option: Leave existing
headers as-is, and create a new, cleaner header.  Or, alternatively, new
code that wants a cleaner namespace should #define MINC_USE_NAMESPACE
(or similar), before including any MINC or volume_io header.


> this should only be a problem for Dave Mc's proggies.
> I have never (knowingly) used the 'naughty' #defines in volume_io but will
> probably be proved wrong here. ;)

The problem is: several of these (including ABS, MIN, and MAX) are
listed in the volume_io documentation.  Abruptly changing the published
API (abhorrent though it may be) in a point release is probably *not* going
to inspire confidence in the maintainance process of MINC...

Perhaps we could introduce a symbol to clean up the namespace (e.g. the
MINC_USE_NAMESPACE symbol suggested above) and document the old
stuff as "deprecated".  Also: encourage client programmers to move
away from interfaces documented as deprecated.

In a future release (2.0 for sure), the deprecated stuff can be moved
to the special compatibility header as you suggest, or removed entirely.
Mainly, we should give people time to adjust their code.

 
> Then we should prefix all current volume_io #defines with something like
> VOLIO_ (GNU'ish style). This should all be fine unless the "other" volio brain
> library comes into play with it's own #defines...
> 
>   re:  http://eivind.imm.dtu.dk/staff/kjems/volio/

That's a good reason to stay away from such a generic name.  Perhaps we
could use "MNI_VOLIO_" as the prefix.  We have a more legitimate claim on
"MNI" than on "VOLIO" as the top level of the hierarchy.



On Thu, Jun 19, 2003 at 09:29:17AM +1000, Andrew Janke wrote:
> On Wed, 18 Jun 2003, Vicka Corey wrote:
> 
> > In specific the ones we've had trouble with include:
> >
> > #define  PI           M_PI                  /* from math.h */
> > #define  ABS( x )   ( ((x) > 0) ? (x) : (-(x)) )
> > #define  FABS( x )   fabs( (double) x )
> > #define  SIGN( x )  ( ((x) > 0) ? 1 : (((x) < 0) ? -1 : 0) )
> > #define  FSIGN( x )  ( ((x) > 0.0) ? 1.0 : (((x) < 0.0) ? -1.0 : 0.0) ..
> 
> So is the general consensus to change just the problem #defines or the lot?
> 
>    $ grep \#define /usr/local/mni/include/volume_io/* | wc -l
>         234
> 
> All 234 of them at that.

I imagine that there should be no global symbols without a "MNI_VOLIO_"
prefix.  I suspect that some of those 234 symbols can simply be replaced:
FABS --> fabs() for example.  I think it is worth going through them on
a case-by-case basis.  Some might be able to be removed to the volume_io
source files or to a header that is not installed.

-Steve