This is the mail archive of the guile@sourceware.cygnus.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: interface reductions


On 24 May 2000, Mikael Djurfeldt wrote:

> I think you agree with this.  But we seem to have a different
> interpretation of "deprecated".  If I, as a programmer, see that
> something is deprecated, that means, for me, that A. I should not use
> it in new programs, ans B. I should try to remove it from old programs
> when I get the opportunity.  But I can't do that if there doesn't
> exist a valid alternative.

Just a clarification from my side:  My interpretation of deprecated goes
along with yours.  However, up to now 'deprecating' a function or a macro
in guile was done by adding a comment /* deprecated */ to it.  With the
new SCM_DEBUG_DEPRECATED macro we can do better than that:  Functions that
are deprecated are placed within a
  #if (SCM_DEBUG_DEPRECATED == 0)
  ...
  #endif
block.  This means that these definitions will appear as usual in a normal
compilation.  Their state being deprecated is obvious because of their
encapsulation in the #if...#endif statements.  The good point is, however,
that developers can now easily check their code for uses of deprecated
definitions, just by doing a 'make CFLAGS="-DSCM_DEBUG_DEPRECATED=1"'.  
Then, the compiler or linker will tell them if they use anything that is
deprecated.  Thus, it helps to avoid such definitions in new code as well
as helping to remove it from old programs.

Deprecating functions this way does not necessarily imply that these will
have to be removed soon, but it obviously is a hint that this might happen
some time.

Best regards
Dirk


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]