Re: interface reductions

[Mikael Djurfeldt <mdj at mdj dot nada dot kth dot se>]

Dirk Herrmann <dirk@ida.ing.tu-bs.de> writes:

> 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.

Yeah, I think this is excellent.

> 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.

But, when deprecating we should both

1. provide a valid alternative (mentioned in a comment)

and

2. determine when it will be removed (which release, that is)

Before each release, we look at RELEASE and remove things which have
been scheduled for removal.

If we can't determine at what release it should be removed because
of some conditional dependency (something needs to be implemented
first), that is a sign that we can't deprecate it.