Re: Handling deprecated features

[Marius Vollmer]

Neil Jerram <address@hidden> writes:

> 1) I'm not sure about using an environment variable to customize the
>    behaviour.  Currently, we already have two mechanisms for this kind
>    of control: (i) command line options and (ii) the (xxx-options)
>    interfaces.  Why should we add a third form of customization rather
>    than use one of the existing mechanisms?

Good point.  I thought of an environment variable first because I
think they are the easiest for people to control when they are using
some application program that hides Guile in its innards.  Not all
Guile using applications might accept the standard command line
arguments, or read "~/.guile".  Changing the code to insert an
appropriate `(xxx-options)' call is likely not feasible either.

Thus, I think a environment variable is good for people who just want
Guile to shut up.

On the other hand, when you--the developer--want more detailed
information, it will likely be no problem for you to insert the
xxx-options incantations, or use any other mechanism that Guile
provides to control the deprecation warnings.

However, the developer can also use an environment variable.  So I
think such a variable offers the least difficult way of getting this
information into Guile.

>    ;;; `xxx' is deprecated and will disappear in a future version of
>    ;;; Guile; please use `yyy' instead.
> 
>    and
> 
>    ;;; `xxx' will be removed in the next Guile release; please use
>    ;;; `yyy' instead.
> 
> I wonder if anyone else thinks this last distinction would be useful?

I don't know.  I would rather not worry about this too much.  I think
I'll first implement the basic stuff outlines so far, and we can then
see how to improve it later.